We need security for animations.

[Aasha Kohime]

Fellow animators,

There's a pretty annoying security issue for us. Many of us that have specialized in this field have probably known about this a good long while but animations are easily ripped off. If you add animations to something attachable at the moment there's no way to keep someone from being able to take it out of the object. 

llStartAnimation only works with actual contents. Why? LL has never given a valid reason. I've read from past posts that they say it makes them harder to steal. It probably did help keep people from just grabbing the UUID in the past, but what's easier to rip? The UUID of an animation in a script, or an animation you have in the actual contents of your weapons, dancers, furniture, vehicles and AOs? Imagine how hard to steal  textures would be if textures had to be included in the contents. Much easier, right? Exactly.

I've started a jira bug report about it and they closed it with the vaguest explaination possible. https://jira.secondlife.com/browse/BUG-8162? (Notice other animation based bugs of the same nature reported in it's links are still standing). Even following up and IMing the Linden why directly provided the equilivant of vague prerecorded messages before they logged off.

TempAttach seemed like a light at the end of the tunnel to me at first but even that was found to leave the item's contents rippable after a little testing. It takes a little knowledge, but you can do it easily with any viewer once you know how (I hesitate to explain the process publicly though).

The way things are set up now people don't even need a copybot viewer to rip animators off.

I'm working on a DMCA to have ripped animations removed but I have a feeling LL's mentality is to sweep complaints of this nature under the rug and hope it goes away by making it inconvienent for us to persue. So I'm making sure everyone is aware of the issue. LL is more likely to make it less possible to rip our work off in the future if we're aware of it today.

[Matt Helstein]

if we could just use animation UUIDs more readily this wouldnt be neer the issue... I don't understand why that isnt availible to us. I'll be showing a lot of my friends to this issue hopefully to raise awareness of it.

[Bootz Crane]

It does seem like a good idea, here's hoping it doesn't fall on deaf ears cause you seem like you know what your doing.

[Creshosk]

Yeah, gestures show that you don't need the actual animation file in order to trigger an animation.
Sound files also can be triggered in a script without having the actual sound file.

So there's notreason why you'd have to have it in there from a technical stand point.

That temp attatch non-sense has a security hole.  Sure it keeps the shell from being taken, but the shell can easily be replaced once you get the contents.

Having an animation UUID in a no-mod script would be more secure. I have no idea who thought that having people have access to the actual animation file itself made it more secure.

Sound files and textures can be harder to get ahold of because they can be embededed in a script. Which means you'd need that script. And there are several more ways to control your script working the way you want it to.

It's easier to have an object that only plays sounds under certain conditions. With animations you HAVE to have the animation in the object, and since they can be ripped out of no-mod objects the script replaced so that trolls and griefers can still trigger the animation in places you don't want them to.

So not only would this secure things for the animator, it'd also add more security for sim owners.

[Aasha Kohime]

Not to mention simplify things. Replacing the animation name with the animation UUID just feels pure and simple compared to the hoops I've gone through lately. Scripting things to only work in one sim. Scripting temporary attachments. In the end even with all that it doesn't work since when you get right down to it people can still more or less legally steal from you.

[Fermi Torok]

From when I began my time here in SL until today, LL has always done their best to make it clear that protecting creators within the virtual world would be one of their greatest if not highest priority. I completely agree that something needs to be done to help animators who don't want to physically distribute their animations as inventory objects, but to include them as packaged works with scripts, (via UUIDs) which would be much safer.

 

Moving towards the release of the sequel for SL, securing the content of both platforms should be of the absolute most importance.

 

LL, if you're reading this, this is your chance to show the community and those looking to join that the time they invest into creating content for your current platform and its sequel will not be stolen and exploited by malicious users. More content means more community means a bigger, better, and safer SL.

[Perrie Juran]

The problems with Animations dates back to the Early Days of SL.

I asked about this last March trying to understand some of the logic.

As simply as I can see it the problem lays with how animations behave and are implemented.

I'm not saying it can't be done nor am I implying I am against it, but it appears to me a serious retooling of the permissions system and how animations are implemented in the Viewer would be needed to accomplish what you are asking for.

I'd sure love to be able to use no copy animations in Gestures. 

[Callum Meriman]

Animation UUIDs are trivial to obtain. There is an LSL command to obtain the animation being played of anyone in the sim.

Walk into a danceclub, play an animation from their danceball, start your one line script and see the UUID. In fact, to show how trivial it is, here is the script off of the top of my head (it should compile I hope). Feel free to try it when you play your secret UUID.

default {touch_start(integer num) {  llSay(0,llList2CSV(llGetAnimationList(llDetectedKey(0))));}}

There are other ways too, the console in advanced and various tricks with the viewer logs. 

One of the console methods is fun, it shows the UUIDs of the animations being played by people above their heads. Just turn that on and watch what the hovertext over each person lists as the UUID. (My script is likely easier though as the UUID can be copy/pasted)

So what if people can extract an animation from an attachment. Make it no-transfer and they can make a million copies but those copies never leave their inventory. Or, make it No Copy and once they extract it once the attachment is broken.

Even put in your script a check for the animation in contents and llDie() to kill the object if someone deletes/removes the animation (be prepared for the angry support contacts though if you do this)

[Aasha Kohime]

I already covered that in the jira bug report. Simple fix: Only allow scripts to play animation UUIDs if the creator is the same for both.

[Callum Meriman]

I am not sure that is a valid technical solution.

Unless you have practiced good security your entire life and never given anyone a full perm script... then there is a basis someone can use one of these scripts to play your UUID only animations.

I give out full perm scripts to my friends all the time, should your suggestion be taken up, then any of them could use my script just like a faked notecard and have something they write but with me as the creator. All of these people could play back every single animation I ever create, without limit... and give them away for free. Also, everyone they give a full perm script to with me as the creator can do the same.

Sure, your account might be a perfect cleanroom case and not at danger of this, but many people won't have this "safety".

 

You are saying with this "Let's lessen security on our animations to that of all our scripts we've ever written back to day 1"

[irihapeti]

i support your jira for the reason that is more convenient for the creator in some cases to not have to pack lots of animation files into the contents of their products

some creators will continue to pack. Others will go the UUID way if the option was available to them. More options is good. So I support for that reason as well

basing your jira on sec rationale is not a runner really. bc of what others have said already. Convenience yes. Sec no

[sirhc DeSantis]

Agreed. The convenience would be nice but after all this time - I have too many scripts created by me out there to make use of it. Support going for a way to run anims via UUID - just not with that caveat

[Aasha Kohime]

     True point. Past full-perm scripts could be potentially dangerous for many animators. Unless it only effected scripts created after the date of the hypothetical update that enacted it. I'm completely uncertain if that could be done smoothly though.

 

Another idea then:

     Add a 4th checkbox to the no-mod, no-copy and no-trans list. A "no-contents" checkbox that denies any emptying the contents into the inventory or direct manual opening/playing the contents (the actual name of the checkbox could probably be clearer but that's beside the point). This would benefit quite a mountain of creators but especially the animators.

[irihapeti]

the sec issue is when able to use the viewer controls to extract the contents out of a no-mod prim

the viewer needs to be able to do this for the root prim. So that Open and Copy/move to Inventory works for no-mod prim vendors. Which is a good thing. Seller able to set their vendor to no-mod while also allowing the contents of the root prim to be moved/copied to Inventory by the user/customer

+

the issue now is about preventing the contents of child prims in no-mod linksets from being extracted using the build edit tool

from a sec pov were this prevented then having the assets in the child prim contents would be more secure than using UUIDs

+

eta:

modding the current permissions system to add new flags is a massive undertaking. When start doing this then all kinds of other possible perms come into play and is heaps of them that people have wanted for years for their each own use case. Hopefuly LL will look into all of these in the new Like SL But Better World

so I think that is more feasible at this time to look at other ways to address the sec issue as it impact on the problem you have identified

 

 

[Creshosk]

So just make any script function that returns the keys depreciated or like with textures make it only work if the script owner matches the animation creator and/or only works with full perm copies. After all you can't run a script to tell you the uuid of a texture unless there's a full-perm copy of it in the inventory. Do the same with animations.

I mean it's not like functions haven't been depreciated and removed in the past.

What's weven the point of retrieving keys of animations now if they're not used in scripts anyway?


And the UUID being displayed over an avatars head debug function presently only works if its full perm. otherwise it just displays as a null key... which of course makes it difficult sometimes when an animation refuses to stop even using a script to stopp all animations or using the veiwer to stop all animations.

[irihapeti]

the blocking of asset UUIDs is a viewer effect only

for example the disabling of Copy Asset UUID menu in Inventory when is not full perms. The UUID still gets sent to the viewer and some viewers make this easy available to the user in them viewers User Interface

+

about the anim can only be run if the creator is the same for both the script and the anim/asset

if I have a anim made by someone else and I also have a full-perm script made by them then is a problem for that person. No problem for me. A problem for that person

for new creatives then this is not so much a issue. Is a big issue tho for many people who have been in SL a long time. For example anim creators who gave away scripts full perms (like AOs and dance HUDs) with their products as a service to their customers (and still do some of them) so that their customers could easy use the anims, were able to mod the script to go how they like, and maybe come back and buy more anims

[Sassy Romano]

---

Creshosk wrote:

 

Sound files and textures can be harder to get ahold of because they can be embededed in a script. Which means you'd need that script.

 

 

---

If this is the premise of your security function, think again.  The standard viewer gives up this information in a wink.

[Aasha Kohime]

That honestly seems like something they can change. Just like they had viewers change to suit security in the past. Make it so it's only possible to get the animations' UUIDs if they are full perm. Logically yes people can still find tricks to get the animation. The same way they do with everything. But it'd be harder.

Anyone that used tools and functions that managed to see through the perm restrictions and get the UUID would be treated the same way anyone that used a tool or viewer that could copy a texture or object would now.

[Sassy Romano]

---

Aasha Kohime wrote:

That honestly seems like something they can change. Just like they had viewers change to suit security in the past. Make it so it's only possible to get the animations' UUIDs if they are full perm. Logically yes people can still find tricks to get the animation. The same way they do with everything. But it'd be harder.

Anyone that used tools and functions that managed to see through the perm restrictions and get the UUID would be treated the same way anyone that used a tool or viewer that could copy a texture or object would now.

---

How do you propose that the viewer plays an animation which is NOT full perm when the viewer needs the UUID regardless of permission?  Animations are a client side render and the asset has to be downloaded to the client first regardless of SL permission.  The asset is downloaded via UUID, just like every other asset.

Further, my question then is that an asset UUID can be discovered by anyone with the right knowledge using nothing more than the standard SL viewer and inspection of their cache.  If I then apply a texture to an object by UUID, I haven't re-uploaded it, I haven't obtained it via any nefarious viewer so how are you suggesting that you treat me?

 

[Aasha Kohime]

"Animations are a client side render"

That there looks like the first place to start the fix.

[Sassy Romano]

how are you going to do that without massively changing the way that SL works while maintaining backward compatiblity?  That's pretty much why the JIRA was closed, it's not going to happen.

Plus, with animations being rendered client side, the speed of the animation is not affected by server simulator load.  No, trying to move the rendering of animations to server side with the current platform would not be a good idea at all!

[Aasha Kohime]

I get my idea isn't perfect. But the bottem line is it's their (LL) job to figure out the how. What they have set now is not working. What they have right now pretty much gives the animation itself away if people get animated at all. Stop sitting here and acting like because I don't have the magic solution it can't be done. I am the victim here - as are others in my position. LL is the one that should provide the magical solution. So aim all your "how" questions towards them. It's their job.

[Sassy Romano]

Well their solution is simple.  Not doing it for a legacy platform that is now merely in maintenance mode.  Maybe SL2 will be improved in the permissions area.

I'm not sure what the fuss it about though to be honest.  If the object is no mod, then removing an animation from it to inventory does what?  It lets the person move the animation from the object to inventory.  They already bought the animation as part of the product and moving a no copy animation from a no mod object leaves them with a broken object.

If the animation is copy, then why the concern about them having it in the object or inventory, it's COPY!

Nobody has gained anything that they hadn't already purchased and if it's no transfer, it's not going to someone else.

I'm puzzled as to where the big issue actually is.

[Aasha Kohime]

Long story short people ripped animations out of a free sword demo that was scripted to only work in my home sim. As you can assume happened the animations were ripped out by an unknown number and used in other sims.

[Sassy Romano]

Then may I suggest that the implementation was wrong.  If the demo was only to run in your sim, what you should have done is have the animations in a different object and then when they took the demo, the script would only communicate with the demo server.

The demo server would then perform llRequestPermission to animate the user agent and at that point when they agree, the animation runs while remaining safely tucked up in your server object.

No need to put the animations inside the demo sword item at all.