Developer Update - 14 March 2024

Some famous video websites are not supported by yt dlp, so they cannot be played directly. Therefore, third-party servers need to parse videos and redirect them. Therefore, submitting websites with only reputable but unlisted hosts does not solve the problem

Regardless it would still be very unsafe to fully unlock the URL system as it would enable world creators to create tools to spy on people who visit their world including capturing names and pictures of them.

Just need to appropriately remind users that the URL they access carries risks. Currently, it is still possible to use the method of generating links to induce users to copy and paste to upload information, which is not different

Given we’re adding this setting now rather than giving some lead up time with forewarning we didn’t want to go with something too low. I could definitely see the default changing in future (and would support it) but we’d want to ensure people are aware beforehand.

Additionally the setting isn’t aimed to specifically combat VRAM usage but rather targeting RAM usage more, though they are pretty similar.

3 Likes

Good news on that front, we’ve had some breakthroughs around MIP streaming that might actually make it viable for our use case - stay tuned! That’ll mean low VRAM won’t tank your machine anymore.

10 Likes

As someone who only uses public avatars and would like to make sure none of my favourites are lost (I suspect some of the animation ones will be) is there a way to see the compressed and uncompressed sizes of an avatar without being the creator? I assume the download size is the compressed one, is the “texture memory” stat the uncompressed one?

Asking people to do that carries a much lower risk than the world being able to, without your knowledge, take pictures of you and stream them up to a server using base64 URL encoding.

Remember that most people are not in 80 people instances most of the time, quite the opposite. Also remember that these numbers are kinda max values, not everything will always be in that vram when people have toggles etc.

@euan thinking of that, would it not be better to have more seafty settings aimed at total values and not per avatar? Like 300 MB vram in 5 people friends lobby is totally fine, but in 40 people lobby probably the heaviest could be hidden automatically to preserve vram. This affects all of the settings. I would prefer to limit my vram usage to XX GB, total lights to XX, etc, and then just cut off the most demanding avatar(s) to get below limit again.

1 Like

I have been saying that there is a need for an appropriate way to warn users that they have used link construction, why are users unaware?

What we need is a choice between completely open and completely closed, for creators and players to choose from, rather than being defined by the official VRC

The uncompressed size will be displayed as “Estimated memory usage” both in-app and in SDK. You will be able to see the estimated memory usage in the avatar details of an avatar in-app, so you should be able to see the stat for any avatar you see, not just your own.

The new setting is not part of the safety system and generally the safety system is there for safety, not performance, even if people conflate the usage. On the topic of why not have a total limit it’s because the system then needs to get quite a bit more complex needing more development time of which is not available currently. Beyond that I personally don’t believe it would serve as a good motivator to get people to optimise compared to limiting avatars individually though I don’t believe that is a good enough reason alone to not do it.

2 Likes

will this option work with old graphics cards such as the gtx 960, 750, 1050 and so?

In theory, it should affect all GPUs not just the latest ones.

1 Like

I guess i can understand that, but kinda opposite of what I hope to get from the system. I like to see what people create, and as long as I’m not lagging in the lobby im fine with anything. So sacraficing quality in small lobbies so the big ones can work better is kinda not what I want.

And for optimization I think the best way is to still just give people better tools. Modual avatars + optimizer already can do a lot to at least remove all the unused stuff. Now if there would be also something to automatically combine textures, at least reusing the space of removed parts… my own vram would probably go down by half.
And maybe something for the booth creators to teach them to not uv umwrap this smooth large flat surface into 90% of 4k texture and then pack all the details into remaining 10% with 1px wide lines so you can’t reduce resolution

I think VRChat should just enable impostors automatically for all new avatars at least (and retroactively for some within a period of time), on top of advertising it to users. It’s such a useful feature that no one is taking advantage of.

2 Likes

VRCUrl construction needs to be available for all URLs when “Allow Untrusted URLs” is enabled, not just whitelisted domains. This feature is useless unless I can use it with my own domains otherwise it’s going to be the same inefficient process of pre-generating massive lists of URLs to accomplish the same task that a single function call should be doing.

2 Likes

Yea but also issue is, some users may NOT want to trust those websites, heard of bunch of such cases.

2 Likes

What’s preventing someone from doing that already? They could pre-generate dozens or hundreds of URLs and request them based on usernames or other things, and cache that to be relayed via every 5 second limit of a request. Especially so if they use combinations of letters for common names or something.

You could easily exfiltrate various forms of data over time. Think about people that spend hours or even days in instances. What about public instances?

This is entirely possible already because most people turn on “Untrusted URLs” because of movie and other worlds. The security here is flimsy.

It would be much more robust to have a temporary allowance that the world can request, which clears after they leave, or after a period of time. Especially so if the user can manage this list of allowed URLs, versus allowing “all” URLs.

It could even be similar to how android does permissions. Have World creators specify what types of data they will collect, and the user is presented with a popup to allow a URL (temporarily, not permanently). Discord already does this in a basic form.

It would completely remove the need for “Allow Untrusted URLs”, unless we wanted to allow users to manage a list of allowed URLs (could max out by default at 30 days).

There’s a lot of ways to actually solve this problem. I find it strange that they are hodge-podging it in this way.

The only thing I can think of is that there is (allegedly) a XSS (Cross-Site Scripting) attack vector with URLs and Udon, where apparently people can theoretically load an Udon script from a URL and execute whatever code they want. This is not verified though, just a rumor I heard through observation of how the Udon VM works.

I LOVE YOU GUYS! I’VE BEEN WAITING FOR THIS!!! :sob::sob::sob:

2 Likes

I agree with what you said. We are not completely overthrowing conservatism and adopting a radical and completely open strategy, but we need a power that allows players to choose

1 Like

We’d love to do something like this eventually! To protect the privacy of users, it would probably require a more granular permissions system than the current “Allow untrusted URLs”.

7 Likes