Idk why, but ever since the last update, VRChat has been crashing on me multiple times the past two days I was on. It’s not my computer. The program itself would freeze, and had the “VRChat Loading” icon before ultimately closing. Steam was fine. It happened 7 times within 3 hours with friends on Friday, and I wasn’t the only one crashing. Last night VRChat crashed 4 times within 4 hours.
Idk what’s causing it, so I don’t know how to repeat it. I’ve never had this problem before.
Momo expressed here that the rate limit is to make it “harder and slower to exfiltrate user data via GET requests to third-party servers.”.
As far as I am aware, VRCUrls can not be changed at runtime, and the only instance where a custom VRCUrl can be made is with a VRCUrlInputField at the explicit consent of a user. Momo also expressed that there is no exploit for the VRCUrlInputField. So I am unaware of how anyone would exfiltrate user data automatically.
But either way, can we not try to work towards better accountability tools? Ways for users to see the requests and their data, plus ways for users to report domains or worlds? This way, world creators can be more free with their world creation, and we can address problems as they arise?
Also, Momo mentioned that they can’t really explain the possible exploits. To me, the system seems sealed and leak-proof currently. Udon runs in a VM and the types make it physically impossible to send custom requests without explicit user consent, where the only way to alter this is by modifying the client, which is impossible without the user themselves doing it, nor with EAC.
Security through obscurity is not security. I would prefer if VRChat stopped preventing or reducing features for the sake of a perceived problem that may or may not happen, or that may or may not be an actual problem (easy to remember: the argument against avatar scaling).
You don’t need to rely on standardised methods such as dynamic URLs to transmit data. It’s possible to send data with any method that allows for the encoding and transmission of a pattern, for example, with carefully crafted request timings or URL access patterns. This would be trivial to implement. The rationale behind the request limit makes sense in that regards.
True watertightness doesn’t exist on the internet, only differing degrees of leakiness.
I’m not sure how useful it would be for users to see requests. Most people don’t have much of an understanding about how any of this works and lack the technical skills to discern potentially malicious requests. Sending data as detailed above would likely slip past even fairly technical users. This may be a useful tool for some and certainly something that would be nice to see regardless.
VRChat might have some legal accountability here, what with all the recent laws around data collection. It’s the VRChat application that would be ultimately collecting and transmitting user data, even if someone else was the creator of the world. You could argue that it’s not VRChat’s legal responsibility, and you may be correct, but I suspect that the company would just not deal with that in the first place.
‘Security through obscurity is not security’ I’m not sure what you mean here. Reducing/limiting functionality and features isn’t obscurement. Everything about this system seem quite unobscured.
But you can not modify the VRCUrl during runtime, and the user needs to manually input a copied URL to send a custom VRCUrl request. So unless the user sat there and spammed the input, or someone created a bot, or someone managed to still use mods (and make a popular world where this can be abused, where they have access), then that singular reason for the rate limit to exist is false.
For sure, and I’m sure with time someone will find various ways to exploit certain things. But how can we even get there to patch those exploits if there is such a hard limit?
It’s less about everyone perfectly scanning the requests, and more about people noticing patterns. If they notice that a few worlds from different creators use the same URL and it seems to be constantly sending data, it could be an indicator that those worlds/that domain are malicious in some way, unless the domain is known.
Same is true with FOSS software. 95% of users don’t scan the code for bugs or exploits, but many do anyways.
There are two very specific VRChat worlds that exist right now that can get VRChat in much more trouble, but they let them slide, so I beg to differ on that statement. Also, how much worse would it be for VRChat compared to what browsers currently do?
I’m talking about their unwillingness to share what the possible other exploits are that they are considering. Not sharing exploits doesn’t make the exploits go away. My only guess is that they know there are exploits with having a lower rate limit and they are currently working to fix them. But even then, the reason they gave for the rate limit (reduce exfiltrated user data) still doesn’t make sense, since runtime VRCUrl modification does not exist and is physically impossible without a modded client on the users’ end (even if then, because Udon is run in a VM).
My example given does not require dynamic URLs in any way. I suspect it’s pretty similar to what VRChat are hinting at in that canny thread. I don’t want to detail it much more than that, as they don’t appear to want to give anyone ideas (even though I don’t approve of this approach—see bottom of post)
It’s less about everyone perfectly scanning the requests
I just don’t think what you describe would solve the issue at hand. It’s not a solution except perhaps for a very small number of people who are capable of using it. It’s a useful tool to have in general, but I can’t see it doing much for the broader data gathering issue.
There are two very specific VRChat worlds that exist right now that can get VRChat in much more trouble,
Yes VRChat has other issues, but that’s not much of a counterargument.
Also, how much worse would it be for VRChat compared to what browsers currently do?
This kind of strikes me as an odd example, given that’s often the very thing that’s at the heart of user data privacy issues.
I’m talking about their unwillingness
Your paragraph speaks of features and restrictions, so it’s a bit confusing.
But regardless, I do agree with you here. I don’t see the benefit in them keeping a known exploit secret, especially when they have supposedly solved the exploit. They might as well just detail it.
Then I would appreciate it if you could explain how a world creator would manage to do this sort of data collection without dynamic URLs. If there is an exploit so sensitive that just suggesting the idea may cause problems, then perhaps string loading shouldn’t be a feature? Based on VRC’s past history of implementing/not implementing features based on security or safety, I would be amazed if there are such sensitive use cases that they’d roll out string loading in such a state.
Oftentimes, no one solution can solve one broader issue, really. And this was just an idea. I wouldn’t mind seeing and testing the domains that a world uses to ensure my own safety. And then my own research can be used to help against worlds that may abuse the string loader. It isn’t a catch all solution. Just one piece that was a suggestion.
You brought up legal ramifications. I provided an example that, in my opinion, has much more impactful legal ramifications.
Again, legally. Have you seen browsers held legally accountable for malicious websites?
Apologies if it is confusing. I do edit my paragraphs sometimes and they end up being out of order. I was referring to Momo’s unwillingness to share the exploit information in the previous paragraph. I.E: Hiding exploits that they know of is not a security feature. If a feature has exploits, it is better to roll back the feature and fix it while explaining the exploit, or list possible exploits and fix them. Heck, VRChat could even do a bug bounty program where they give rewards to users who find and detail exploits.
Yep, exactly.
without dynamic URLs
You can encode data using frequency and count of requests against a static address that can be measured server side, much like old pulse dialing.
Alternatively, send a carefully ordered series of requests against several static addresses, like some sort of frequency-shift keying system.
I suspect that’s roughly what they are referring to. It fits the description of something that works with static URLs and can be slowed (but not stopped) with a rate limiter.
And this was just an idea
Nah fair enough. If VRChat continue to implement web stuff in the client, such a tool would probably be useful in general at some point anyway.
Again, legally. Have you seen browsers held legally accountable for malicious websites?
I don’t think they could be held legally accountable in my layman’s opinion, but I’m pretty sure VRChat are just trying to avoid these issues in the first place.
Apologies if it is confusing.
No problem. I do the same thing 
Ah, that makes a lot more sense. Thank you for explaining.
For sure. Though I wish they would lean into it a little more. Live on the edge a bit. Laws already exist (or often lack of existence) around certain data collection and liability. I think it’s fair to say that if VRC is already playing one card for those specific worlds, they could play the same card here. It wouldn’t be VRChat’s responsibility if they warn the user ahead of time and provide adequate blocking/testing tools for users to check worlds for abuse.
I just wish all this fear around the issues weren’t so prevalent. I would trust a world even POSTing data (well, as long as I have the ability to block it/whitelist) versus smaller companies otherwise. I remember when I changed my password for my apartment’s account system and they printed my password in plaintext when I went to the office for my move in day.
This is why, for example, I wish we could have things like the near-clip distance to persist on restarts, perhaps from the config file. This way average users don’t run into the issue and it resets for them, but as a power user, I can have it set to “dynamic” all the time, since I very rarely find worlds that will break with dynamic clipping on.
And again, their argument against avatar scaling. They were saying something about “imagine someone scaling themselves while trying to talk to you” or using the scaling feature to annoy users. Yeah, that’s when you use the block button. There are far worse offenses from avatars abusing features. People need to have thicker skin, really.
I really wish we had the ability to manually block to a fallback avatar… the blocked avatar is half body and I’d like to see someone’s full body movements even if I don’t see their avatar.
Similarly I wish there was a “full hide” option that didn’t even show the robot… I personally don’t block people because of the bidirectionality of the feature, but in cases of someone obstructing my view (maliciously or otherwise) I’d love to make them transparent while still letting them see and hear me.
Awesome update! (a bit late I know)
I’m curious as to why everyone is begging for faster loads on full 2k images… That seems really painful. However I do think a 5 second delay between downloads might be a bit limiting, would it not be smarter to batch a few of them every 5 seconds or perhaps lower it to half of that value? Or maybe just rate limiting everything to a specific download amount instead of the arbitrary 5 second rule, this could also work to help mitigate image downloads as well, while being more streamlined.
As for the Download Prioritization, thanks for finally adding this! It’s gonna help a lot to stop crashing when I forget to ahem turn on my distance hider when joining larger worlds. Hoping to see some more additions in the future like perhaps API handling of avatar stats, so we can download based on our safety settings.
Keep it up! Love seeing the more frequent updates as of late.
edit: I forgot to mention, because these are loading from the web does this mean images are straight up just the original format? Doesn’t this leave room for HUGE file sizes on images that are 2k in size but have little to no compression and super high color quality?
This can be solved with a bitrate throttle, or even allowing the user themselves to set a rate limit. And we aren’t explicitly asking to load tons of 2K images. I don’t mind if I use 256x256 or 512x512 images (or really, whatever size is provided). We are asking for the ability to consume APIs that may have dynamic images or require us to call multiple endpoints (mainly for string loading, not image loading).
It depends on what they accept in the image loader or what can be converted. Yes, this does allow the opportunity for someone to load RGBA images that are just raw data.
Either way: Sure, let them. VRChat should not really be responsible for limiting APIs from being consumed or to explicitly prevent abuse with the image/string loading. What they should do is give the users tools to moderate their experience as they see fit.
I have gigabit internet and can probably handle 1000 requests per second to my own webserver or an external webserver. I don’t care. If a world is poorly optimized, we know to just not go there anymore (which is something we already do).
Like Momo said, the biggest issue is data exfiltration, and there are ways to extract data by having plenty of preset API end points (for example, having endpoints for each letter of the alphabet and then spamming tons of requests to encode data). But really, I think that should be allowed. I even think POST requests should be allowed.
Like I said, VRChat should provide tools so the user can moderate instances for themselves. I should be able to decide if I want to manually whitelist each instance, and even granularly allow GET vs POST. I should also be able to see all the requests so I can at least try to determine if a world is being abusive with web requests.
The more you arbitrarily limit, the more people are going to try to circumvent to the point that the limits you have won’t do anything anymore. If people have the choice to exfiltrate data or reduce rate limits, there is less opportunity for exploits to be found that would break the original limits.
Good, security by obscurity isn’t ideal. Put the limits right in the front lawn so anyone can see if they get circumvented
Personally I feel like this feature is good for adding just that little bit more to a world. I hope I don’t accidentally miss the comic vket but there are comic samples that are implemented using video to download the atlas, I believe each person can be Reading thier own sample at a time, and if you pick up one, it just says loading until it’s loaded. Maybe some people paw through them really fast, but I’ve found I look at the art and walk slowly enough that all in: the 5 second timer is well expired by the time I pick up another.
Quote of the day? Event calendar? Maybe it’s because I grew up with the internet but I don’t see it a huge problem if I load into a world and can’t immediately see the world authors latest tweet. Make sure you load the calendar first.
I believe the current system will accept jpg and PNG. Uncompressed raw texture might download but would fail decode.
Another later Dev Update today, so many meetings 
Stay strong!