Assets with avatar protection can be spawned and persist in worlds without the associated user

[gentlecolts]

Describe the bug?

When a user leaves a world, assets with avatar protection associated with that user remove themselves as well. However, recently I discovered that assets with avatar protection spawned not through the inventory (ex via things like RedX) will in fact both successfully spawn and persist

To Reproduce

I do not personally know the exact mechanisms behind cloud spawning or whatever such tools are using, but see previous section for how this was discovered

Expected behavior

avatar protection should perform a check on spawn to ensure the corresponding user is present, and delete as if the user had left if they are not. Ideally, the engine itself would prevent such items from spawning in the first place, if such behavior is possible

Screenshots

No response

Resonite Version Number

Beta 2024.9.4.357

What Platforms does this occur on?

Windows, Linux

What headset if any do you use?

No response

Log Files

n/a

Additional Context

No response

Reporters

zangooseoo
ZeeMakesThingsGo

[shiftyscales]

spawned not through the inventory (ex via things like RedX) will in fact both successfully spawn and persist

It would help a lot if you could provide context for how / why this condition happened in the first-place. Unless a user has placed a protected asset in a public folder / other publicly accessible place, there shouldn't be a mechanism for spawning it out arbitrarily.

This issue also has a lot of overlap with #626 in which I'd previously commented:

This issue would be covered implicitly by the introduction of a licensing system.

Additional protection would be offered in the form of #1103.

• Low level write/modify validations of the data model, locking down parts of it from being modified by users (even in case of malicious client which bypasses the restrictions on user's end)

[gentlecolts]

It would help a lot if you could provide context for how / why this condition happened in the first-place

The situation that led to this ticket was that Zee had happened to spawn some item from RedX. I thought it was neat and attempted to save it, however noticed I couldn't. Inspecting the object revealed that it did in fact have avatar protection on it which was associated with a user who I am unfamiliar with, and was not present in the session.

I'll further add that I do not know what mechanisms RedX uses for indexing or spawning assets, only that it's a popular enough tool for this to be concerning, Resonite should as much as possible not be allowing avatar protected assets to be present in a world without the owning user.

[XDelta]

Spawning stuff from redx or from a public folder can have avatar protection applied to it which will stop it from being saved. The owning user doesn't have to be in the session. If they then join and leave, any of their avatar protected things will be destroyed.
If you save the world, those items will just be deleted similar to anything that is non-persistent.

[XDelta]

Redx is just indexed public folders and items in them.

[Frooxius]

We won't be making this change for two reasons:

1. As we mentioned many times before, SimpleAvatarProtection is very fragile and any changes to it tend to break things horribly
2. Some people have been using SimpleAvatarProtection to protect things other than avatars, like worlds they publish. If we were to make this change, this would destroy those worlds, because they would all de-spawn on load

The second part is a good example of why we stress not hijaking systems for purposes they were not intended for - whenever you do that, it makes it difficult/impossible for us to make certain changes without significantly breaking things that have already been built, effectively "locking in" the current patterns of behavior.

To really deal with these kinds of situations in a proper manner, we need a better system that would be covered by:
#626

[gentlecolts]

2. Some people have been using SimpleAvatarProtection to protect things other than avatars

That doesn't change that this behavior, to me, seems to indicate that there'd be the potential for people to spawn out other people's avatars, the intended use case, in sessions where that user is not present.

How widespread is that misuse even? Not to say I don't believe that it happens, but I've personally never heard of people doing this, especially since if I'm not mistaken, existing systems can achieve the misuse mentioned in that 2nd bullet.

[gentlecolts]

Spawning stuff from redx or from a public folder can have avatar protection applied to it which will stop it from being saved

I find it troubling that people are doing that as it sounds like a horrible misuse of avatar protection, and this is not behavior that should be encouraged

[shiftyscales]

Per Frooxius' response above, and per my previous response, there are already better existing / planned issues which better cover the needs expressed in this issue.

It is not worth putting additional dev time into the simple, hacky, broken protection system when that time could eventually be put to the more robust option- particularly considering this issue only seems to pertain to the niche condition of requiring a user to save their protected assets in a publicly accessible location in the first-place.

[Frooxius]

2. Some people have been using SimpleAvatarProtection to protect things other than avatars

That doesn't change that this behavior, to me, seems to indicate that there'd be the potential for people to spawn out other people's avatars, the intended use case, in sessions where that user is not present.

How widespread is that misuse even? Not to say I don't believe that it happens, but I've personally never heard of people doing this, especially since if I'm not mistaken, existing systems can achieve the misuse mentioned in that 2nd bullet.

Enough to cause issues and make people complain. The change you're proposing is actually something that was implemented in the past, but it exploded a bunch of things, so we had to revert it. And it's why I don't want to touch it again.