it 'fails' for just the same reasons as before. as you say, its not going to be something you can ever make totally locked (perhaps quantum encryption will in the end?), just as bigger deterent as possible. but on a pretty fundamental level, its going to be mighty hard preventing commands being passed to the console. like i said above, i reckon we just need alias to implement a little flag that the file manip commands look at before preceeding, unlockable by encrypted password ... at least that way, you'd have to go bust open the binary and spend some cycles trying to crack the encryption (they could be quite hard if they somehow non-intrusively embedded it in your scene structures, so itd be peculiarly unique to ea scene. but then this embedding method would be decipherable of course, but may still make teasing it out difficult [and for the real decrypter too, mmm]). i dunno.
maybe you could provide the scene w a boot file that constructs a maya session omitting as much of the command interface as possible (you prevent sourcing of all user prefs, and the interface to constructing command execution methods - MM/hotkeys/shelves). kill commandPort support. gotta kill import somehow .... scriptJob on file read? even seemingly innocuous commands like generating some particles, and caching them, could shadow geometry to disk. mmm, PLE (goes and looks on site: disk caching disabled. figures, id be surprised if they'd missed that one!).
... ahh, yeah, then youd have to prevent the user from editing this setup file. ....so somehow make the scene only load correctly if it finds itself in this right environment? a method that doesnt allow it to be caught before it realises this and self destructs.
nah, thats naf. you would hardly have a functional maya session left ... tho, all you probably want is navigation, playback, select, transformation. you'd have to provide all the scripts to be sourced w/i the scene body (like your already doing), else the usual ones could just be subverted. maybe this is possible ...
i dunno ...
