Replies: 5 comments 10 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.
I'd say that this has overall more benefits than a proxy server because:
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
It's a really cool idea, but sadly not free and open source software. The license is for non-commercial use only. |
Beta Was this translation helpful? Give feedback.
-
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:
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:
xyz.com/alice.fst
overte.org/alice.fst
.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.
Beta Was this translation helpful? Give feedback.
All reactions