Avatar Protection Mechanism AKA Security theater and how I learned to stop worrying and love the framebuffer

[Zetaphor]

The Problem

There has been a lot of lively conversation today between the Overte and Neos communication channels about the concern and possible solutions for avatar/asset ripping. It's been expressed that a concern about transitioning to Overte is the open nature allowing for anyone's avatar URL being hijacked and their identity/ownership being distributed without consent.

A number of solutions have been discussed (and frankly this topic has been discussed to death), but I'm making the argument that there are and only ever will be two final solutions to this problem:

• We implement draconian measures that are in opposition to user freedom by installing kernel level anticheat so we can ensure that users operate in a safe and sanitary environment.
• We implement enough security theater that users feel comfortable enough to upload their assets, and accept the fact that the only guaranteed way to prevent content theft is to stop anyone from ever consuming it.

There has been proposals mentioned that involve various mechanisms of cryptography, providing lower resolution versions of avatars, or circles of trust, but I argue that these are all inevitably subject to failure. Cryptography and circles of trust assume that people you do decide to share with won't ever act maliciously. Serving lower quality versions of an asset is going to be a non-starter for most people once they realize they can't have their 4K textures and fancy high poly details.

At the end of the day if you're not going to make me install kernel anti-cheat, I can just install Ninjaripper and steal any polygon that passes through my VRAM. There are no unbreakable locks, there are only locks that are difficult enough that they deter all but the motivated actors and give us good enough security that low-effort theft isn't possible. Content ownership in a realm where scarcity is artificial is a purely social construct, you can't DRM your way out of a social problem.

The Solution

So once we've established that we only need to create enough of an obstacle for people to pass a threshold of safety, we can start exploring viable solutions that aren't laden in high complexity. Fortunately there is a solution already being used by practically every platform that serves content from an asset server, you simply validate that the client requesting the asset is a trusted source (to the best of your ability) and then proxy the asset URL.

Here's what this would look like in practice:

• Alice hosts her avatar at xyz.com/alice.fst
• Bob joins a domain where Alice is present and his client wants to render her avatar.
• Bobs client contacts the global services server and provides some information that proves (as best it can) that he is a trusted actor. This could be information like client ID, request headers, or a session authentication token.
• The server validates Bobs basic information and returns a URL to Alice's asset, ex: overte.org/alice.fst.
• When Bob's client makes the network request to that URL, the asset server is internally proxying the request to Alice's asset hosted at xyz.com/fst.

This is how platforms like VRChat and Neos work today, as well as anything else sending assets over the wire at runtime. They're not actually hosting the assets on the same domain (or even server) that the server handling the request is on, they're instead proxying the request to a cloud server (typically passing along their authentication for that cloud server). We could be doing the same thing but instead proxying to the asset domain that the user provided.

This would require that users have a user account in order to opt-in to avatar protection, as you'd need to tell overte.org where your assets are actually held, but this seems like a small compromise. This would look like you logging in and providing a URL and a name for the avatar somewhere in your profile.

You could of course go MUCH further with this mechanism and start talking about doing full cryptographic key exchange and even end to end encryption, but now we're just throwing more complexity at a problem that can always be thwarted by running a tool that rips polygons directly from the framebuffer.

With a mechanism like this in place we'd be able point to it and tell users "We don't expose the URL for your asset, we're using a security mechanism similar to other online platforms". And for 99% of people that security theater will be good enough.

[Armored-Dragon]

I am in total agreement with your solution. A proxy over all does seem like the most reasonable trade-off. That little bit of security in exchange for having an account.

The idea about encrypting an avatar discussed in the Matrix chat was more of a "I authorize this person to view my avatar" message in the form of a decryption key. I don't think you can rip an avatar or asset out of a framebuffer if it doesn't properly enter the framebuffer in an unencrypted state anyway.

[Zetaphor]

I don't think you can rip an avatar or asset out of a framebuffer if it doesn't properly enter the framebuffer in an unencrypted state anyway.

You are correct, there is no form of secure enclave that proceses the data in the GPU.

This hypothetical secure context would also have to be working in cooperation with my operating system to ensure the entire pipeline from mesh to GLSL to pixels on a display remains untouched. Nothing like that currently exists in any consumer GPU or operating system, unless you want kernel level anticheat.

You could in theory pass encrypted data to a shader, but the output of that shader still needs to be unencrypted vertices if you ever want to see anything, and software like Ninjaripper is already waiting until the data exits the shader pipeline before copying it from the framebuffer to disk.

[Zetaphor]

"I authorize this person to view my avatar" message in the form of a decryption key.

I personally don't like the situation this could lead to, which is distrust by default and a splintered visual experience. This also assumes that someone you trust today won't be malicious tomorrow.

Additionally if there was enough demand for this style of opt-in avatar visibility, it could be implemented in the proposed proxy server without ever requiring encryption. You simply check the owning users allowlist before resolving the proxied request.

That said I think it would suck as a new user to enter the platform and only see default avatars until someone decides to trust me. Being among a diverse group of visual identities is part of the appeal of virtual worlds.

[Armored-Dragon]

Either I am misunderstanding what you mean now, or I did a poor job explaining what I meant on an "encrypted avatar". Your GPU / Framebuffer / what ever else handling rendering, or anything close to it would not be the one handling any encrypted data, ever. It would be the game logic itself doing the decryption before processing the rendering. Either the game will find a valid model to then render, or it finds that the model is not valid and uses a fallback to then render.

I don't think avatar ripping would ever get to the point of us even having to consider adding something this invasive; look at VRChat or NeosVR, their community seems contempt without anything as drastic as this. However as "encryption" of some kind always comes up in this wild goose chase of a topic, it's better to discuss it now and what impacts it would have:

That said I think it would suck as a new user to enter the platform and only see default avatars until someone decides to trust me. Being among a diverse group of visual identities is part of the appeal of virtual worlds.

[ksuprynowicz]

As for the proposal with asset server proxy, I'm worried that it will mean trouble when an avatar is infringing on copyright. For example imagine that someone shows up with Mario avatar and then Nintendo ruins life of the domain server owner with a lawsuit.
Personally I don't want to get my life ruined by something I have totally no control over. Of course if community decides to adopt such solution it's fine, but I won't be able to use Overte or contribute anymore.

[Zetaphor]

As for the proposal with asset server proxy, I'm worried that it will mean trouble when an avatar is infringing on copyright. For example imagine that someone shows up with Mario avatar and then Nintendo ruins life of the domain server owner with a lawsuit.

I'm not sure how this applies? We would only be rewriting the URL. In this sense we're no more infringing copyright than if someone were to use a URL shortener instead of posting the actual asset URL.

Additionally if someone were to use copyrighted material in Overte, and rewritten URL's were being held responsible, then couldn't you argue that the platform presenting the content and distributing that URL (rewritten or not) to other users clients for the purpose of viewing avatars is now complicit in the distribution of copyrighted content?

I think users using copyrighted content is an issue, but one entirely separate from this discussion.

[ksuprynowicz]

One workaround for this would be adding proxy not as a part of domain server but as entirely new service. Then person willing to accept responsiblity for it would run it.

[Zetaphor]

Not having a first party solution kind of puts us back where we started. The people asking for this kind of mechanism, who already don't understand why it's theater, don't typically have the technical skills to run their own proxy server. The alternative would be asking them to entrust their assets to a stranger who is hosting on their behalf, which kind of defeats the purpose.

The meaningful performance in this security theater is that the platform itself is making an effort to protect your assets.

[Psychpsyo]

The one thing that this specific flavour of security theater doesn't address is that anyone can just take the asset's file they have in their cache and use that. There's no need to download anything once Overte has done that for you.
So I'd be for at least encrypting avatars on disk so people can't go the close-to-zero-effort "Just take the file that's already on your PC" route.
Keys for that could either be statically built into Overte or be provided by the user who originally secured the avatar. (automatically and unconditionally when you join a session with them)
If the keys are provided by the avatar owner I think this gives a similar level of security to a proxy server.
Here's what it would look like in practice:

• Alice hosts her avatar at xyz.com/alice.fst
• Bob joins a domain where Alice is present and his client wants to render her avatar.
• Alice's client sends Bob's client the decryption key for the asset at xyz.com/alice.fst.
• Bob's client now gets alice.fst (either from cache or from xyz.com), decrypts it and can render it to bob.

I'd say that this has overall more benefits than a proxy server because:

• No account is needed for avatar protection.
• No centralized server needs to be involved at all.
• It's probably easier for an Overte client to verify that another client is legit since it has more context than a proxy server.
• Telling overte.org where you host your avatar is replaced with telling Overte (the game) to encrypt your avatar before you go and host it.
• Avatars cannot be accessed after they are no longer in a session with you. (Your client has forgotten about the decryption key and the decrypted asset)

[Zetaphor]

I know I'm using the "endless arms race" argument, but I worry that pursuing an ideal solution will lead to extreme complexity, which introduces fragility and degraded user experience. If this could be implemented with minimal overhead and no potential to degrade user experience it could be a decent option.

A malicious actor could always intercept the decryption keys in-flight and then save the key and decrypt the cache offline. There's going to be a caveat to any proposed solution which is why I keep calling this security theater, but I don't want whatever solution that gets adopted to come at the cost of the currently seamless exchanges we have between avatars today.

[Psychpsyo]

Yes, this isn't perfect and there is no perfect solution.
Though if the cost of decrypting a file isn't too large, I think this would be less effort than introducing a proxy server (or adding proxying+client verification to an existing server)

I might look into this a bit and see what the performance would be like for decryption.

[ChristophHaag]

I haven't closely followed this discussions, apologies if it came up, but I haven't seen it: https://github.com/PlagueVRC/AntiRip. Do people think it would be possible to fork these things in a way that reuses the backend and only adds a frontend for overte avatars, and is still easy to rebase? If so, it could ease the burden of having to come up with and updating an own avatar protection system.

[Armored-Dragon]

Additional info about the linked project (just for ease of readers):

• FAQ
• Seems to be shader based. The mesh is scrambled and the shader unscrambles it visually.
• Uses keys (stored in a config file?) on local system to use the avatar.

---

I actually thought about doing something like this a while ago, but I didn't think it would make sense in practice. This project though seems to have some really good ideas that would get over the hurtles that I had struggled with relating to this problem.
It may be possible in the future to do something like this (at least exactly how the linked project does it with shaders) in the future as how I understand it Overte does support custom shaders.

The problem I would think, and please someone correct me if I am wrong, is that Overte shaders are easy to open up. From what I can tell from my skimming of the AntiRip project, their shaders are encoded in a way that makes it a nightmare to decrypt for ripping. I'm not sure how secure their encoding is because I've never gone though Unity, but I imagine Overte does not have the same luxury encoding and encryption wise when it comes to shaders.

---

Alternatively if we ever get the ability to dynamically adjust vertices on models, I imagine it would be very easy. You just need to create a Blender addon that would encrypt the mesh the same way the Unity addon does, and then use a client side script to adjust vertices back to the expected position. Only you have the correct "keys" to your avatar, and all of your mesh is moved to the correct position. The immediate problem with that though, is now the actual mesh is physically where it needs to be when it's ripped. It'll likely be possible to rip the model, and if they get a mess, they just record the positions of each vertex in game and feed that back into Blender.

[ksuprynowicz]

The problem I would think, and please someone correct me if I am wrong, is that Overte shaders are easy to open up.

Yes. Open GL shaders are provided as source code. Vulkan would be a nice improvement here, because then you can provide shader as SPIR-V bytecode. You could also strip debug info from SPIR-V bytecode. Such custom vertex shader could be provided together with avatar as a custom glTF extension.

[ksuprynowicz]

I haven't closely followed this discussions, apologies if it came up, but I haven't seen it: https://github.com/PlagueVRC/AntiRip.

It's a really cool idea, but sadly not free and open source software. The license is for non-commercial use only.

[CakePost]

Apologies for the necrobump, let me know if this conversation is no longer accepting any more input or has moved elsewhere. Barring such, I'd like to provide my input here as I participated in those conversations as well and was advocating for one of the solutions you don't agree with. Please hear me out.

There are two points that I see come up in these conversations over and over and I'd like to discuss each of them in isolation. From your messages directly because you articulated them well, they go as follows:

1. I can just install Ninjaripper and steal any polygon that passes through my VRAM
2. Circles of trust assume that people you do decide to share with won't ever act maliciously.

1. I can just install Ninjaripper and steal any polygon that passes through my VRAM

This point seems to come up because there's an assumption that people don't understand that this is possible. While I can't speak for everyone, I personally deeply understand that once a mesh is rendered on a client, the client can retrieve that mesh from their GPU. It is because of this fact that I am not advocating for futile client side obfuscation or other cat-and-mouse arms race techniques. During those conversations, it was pretty frustrating to discuss asset protection because every new person that joined the conversation on discord felt compelled to reiterate this fact. It wasn't their fault as those conversations were moving a mile a minute and it was impossible to retrace the points of the conversations. So I'm highlighting it here to make sure you know that I'm aware and fully understand the surface areas involved with asset protection, and the solution I'm in support of takes this into consideration.

I'm politely begging that you don't tell me this again :P

2. Circles of trust assume that people you do decide to share with won't ever act maliciously.

This point I think is interesting and worth discussing because it highlights how we need to consider the people that need to be trusted when evaluating each solution. For instance, can we agree that there is a difference in security policy between the following options:

• Allowing anyone with a link to access an asset.
• Allowing anyone with an account access to an asset.
• Allowing anyone with an account and connected to the same instance access to an asset.
• Allowing friends only to access an asset.
• Allowing a singular other person(s) access to an asset.

I get the sense that some people here think there is no difference between sharing an asset with a singular other person and sharing an asset with everyone on the internet. After all, if that single person betrays your trust and rips your asset, then you fall back to it being shared with everyone anyway. However, I don't think that's a good reason to concede the feature altogether and I think that overlooks an important premise of access control. When a user is given access control settings, they are given agency over their own security policy. They get to choose who to trust and create their own rules vs having the game decide for them.

The status quo for VRChat, Neos Resonite, ChilloutVR, etc is effectively somewhere in the first 3 bullet points above. (anyone with a link, anyone with an account, and anyone with an account in the same instance). I think there is demand for and a good reason to implement the bottom two bullet points as well (friends only, singular other person(s)).

So what feature am I actually advocating for?

I think you can already understand what I'm advocating for from my discussion above, but I want to be explicit so there's no question.

User assets should be given a setting where users can specify who is allowed to download that asset.

At a minimum I think there should be at least two options for this setting:

• Anybody
• Only People I Chose (aka allowlist)

The options function as one would expect, where assets marked with "Anybody" are allowed to be downloaded by anybody, and assets marked with "Only People I Chose" can only be downloaded by the people specified in the setting.

Assets include any UGC, but the main focus of discussion and most pertinent to this thread is the user's avatar.

This would be my MVP, but there is definitely more I would love to add. In the interest of keeping the conversation focused, this is all that I'm proposing. I can elaborate more design ideas if you're interested.

Usecases and User Stories for such a feature

• A user works hard and puts many hours into a personalized custom avatar that they want to use when hanging out with their friends. With the status quo, their avatar is at risk of being ripped if they visit an instance with a malicious user even when that malicious user is not someone they are friends with. Without access control, the user would need to be vigilant about who is accompanying them in an instance, which adds friction when hanging out with their friends when the group may want to venture out into less restricted instances (Friends+, Contacts+, Public, etc). With this feature, the user can instead add their friends to the allowlist for their avatar and then be able to travel throughout the platform without fear of having their avatar ripped even when venturing into public instances.

• A user wants to share intimacy with another user using R rated assets on their avatars. Neither user wants to have those R rated assets publicly linked with their accounts, however, in some cases simply uploading those assets on the platform is enough for a malicious user to download them and expose the users intimate secrets. Access control will put the control back in the users hands and allow those sensitive assets to only be accessible to the two parties involved.

• A user with access control on their avatar finds out that their avatar has been ripped by someone on their allowlist. This is a breach of trust between that user and the ripper they gave access to, thinking they could trust them. The user still feels like they have agency and control and they know to be more careful in the future with either that specific user or the access control feature as a whole. This is in contrast to having no agency and being powerless at the whims of the platform to implement protections that can prevent ripping in the future. Access control turns a platform problem into an interpersonal problem, the latter of which is more manageable and less damaging for the platform.

Common Concerns for this feature and ways they can be addressed.

Adding access controls to assets takes what is regarded as an unsolvable problem (asset protection), and turns it into a few solvable problems. Some common critiques people bring up are:

What do users see for avatars that they are not allowed to download? We don't want public instances to be full of generic robots.

This is closely related to a similar issue that platforms have to tackle, and that is with new users, what avatar do you give them? You don't want all new users to have the same avatar, and so you provide them with a bunch of options during onboarding. The more options you give them, the less homogeneous your platform looks. Instead of everyone embodying the same exact generic robot avatar, you get a mix of whatever defaults you provide. In the same way, access controls can be accompanied by a fallback, where a user appears as one of the onboarding avatars to people that aren't allowed to download their avatar. To take it one step further, users may be given the option to specify their own fallback, which they can fill in with an asset they feel less concerned with having ripped, but perhaps still represents their identity well.

Nobody wants this feature so it's not worth implementing.

I want this feature. Am I nobody? The trend I see is that technically minded people don't see any value in access control for avatars while sentimental people do want access control. Regardless, I don't think there has been enough effort actually polling the userbases of these platforms to know if there is actually "nobody" that wants this feature.

Avatars are meant to be seen, what's the point if nobody can see your avatar?

The allowlist would be the people that can see my avatar, and the point is that I want them to be able to see my avatar and I don't want the violation of anybody else being able to rip my avatar.

Access control adds too much complexity to a platform and is actually really hard to implement.

I'm not sure how to counter this, after all, the maintainers and contributors know better than I do about what is feasible. It's hard for me to fathom, however, that of all the complexities that go into implementing a real-time social VR platform, that somehow access control is an intractable beast that no engineer could pull off.

Conclusion

When I initially broached this topic in the Neos discord, I had no idea it would turn into the shitstorm that it did. I'll admit that the frustration of having a swarm of people bombarding me with dismissive and snarky retorts for hours drove me pretty crazy and made me lose my cool- I wish I could take a lot of my frustration back. Despite that, I am still passionate about this issue in particular and I'm happy to have a constructive conversation with people that want to participate in good faith. I trust that responses will take the time to read my post just like I took the time to read this thread and all the discussion in the forums I'm in about this topic before dismissing me, and will treat me with respect. I want to advocate for the safety and comfort of the inhabitants of these social spaces. users, creators, developers, and friends.

[ksuprynowicz]

@CakePost The solution you propose does seem aligned with open source ideals, since it does not require obscurity and does not require closed source client or server to work. If you know someone who has time and experience necessary to implement it, I'll be happy to provide advice on getting started with Overte development or other technical details.
If such solution gets implemented, it would be best to have both private and fallback URL setting for the avatars, and also notification for moderators of particular world if they are seeing fallback avatar.

[CakePost]

Thank you for your acknowledgement and I'm glad that you feel this aligns with open source ideals. I agree that including the fallback in the MVP is a good idea and I only excluded it in my suggestion because I've encountered disagreements on how that concern should be addressed in the past.

I unfortunately don't know anyone that would be up for implementing this in Overte but I will keep an eye out. I mainly wanted to post here because the OP was addressing a very heated set of discussions that I was directly involved with and felt the need to make my case because it is something I believe in.

[HifiExperiments]

this is something we explicitly have listed on the asset security page as a feature we’d like to consider: https://docs.overte.org/en/latest/security/asset-security.html#avatar-viewing-permissions

as stated there, I believe it would involve adding new fields to FSTs, having the avatar server download those FSTs before sending anything to other clients (which we’ve done in the past but may have disabled at some point?), and then using those new fields to decide what URL to send to who.