Please make the 5-second restriction for VRCStringDownloader, VRCImageDownloader, and VideoPlayer apply per domain instead of globally
chiugame
Thank you for your continued work on the development and maintenance of VRChat.
Currently, VRCStringDownloader, VRCImageDownloader, and VideoPlayer all enforce a 5-second delay between requests.
I assume this restriction exists primarily as a security measure — to prevent worlds from transmitting data externally without user consent — and I fully understand the reasoning behind that design.
However, this restriction currently applies globally across all domains, and that behavior is causing significant usability issues in practice.
For example, if an asset in a world includes components that use these downloaders, they all share the same cooldown timer.
As a result, even content that should load immediately upon joining the world may be delayed for several seconds — or even minutes — depending on how many downloader requests are queued.
In extreme cases, if just one asset tries to load 30 images at once,
the 5-second global cooldown means those requests could take up to two and a half minutes to complete.
This delay cannot be avoided by world creators, since the restriction applies globally and affects all content equally.
To resolve this, I suggest keeping the 5-second restriction but applying it only per domain.
If requests are sent to different domains, there should be no need to throttle them, since doing so would not increase the risk of data exfiltration.
This change would maintain the intended security benefits while greatly improving usability and load performance.
I would greatly appreciate your consideration of this improvement.
Log In
Jarnefeldt
I’d like to understand some of your points about VRChat’s stringloading systems, since discussions online (including on Twitter) often stop at surface-level explanations without addressing deeper concerns.
The tools in question are:
• VRCStringDownloader
• VRCImageDownloader
• VideoPlayer
________________________________________
You mention the 5 second limit and its purposes. I summerised what i understood from your post and people online.
• Disadvantage: The 5 second global cooldown means content isn’t displayed instantly, which can feel restrictive.
• Advantage: This limit is intentional. It prevents spam requests, reduces server strain, and avoids VRChat or its users being blacklisted by external domains. It also mitigates legal risks by discouraging mass scraping or automation that may be forbidden by these websites.
________________________________________
My personal Security Concerns
• Some communities (Japanese users) have raised concerns about data harvesting. While the system could possibly be abused to collect non personal data, the bigger risk in ways it could be maliciously used. Udon's code runs in a sandbox so actual harm is limited, but a great example of malicious use is cheating in games and getting access to items and development tools not usually accessible by normal users.
• VRChat’s requires explicit opt in for untrusted URLs, which places safety on the user side. What are you as the world creator going to do to protect us from malicious links when your world requires us to use untrusted URLs? Will there be a screening process?
• Tools like VRCStringDownloader blockers exist. Can be used to avoid world bans imposed on players via a list. Can also be used to block Udon elements entirely. Some people use it for safety reasons to stop all Udon code from running on their systems. If abuse happens it could become a very real reality that users turn to these kinds of tools instead.
Jarnefeldt
________________________________________
Intended use Cases and Scope
• What is the intended use case for loading large batches of images? Posters, guides, or advertisements seem like good choices. Advertisements in particular makes the most sense though for world creators. I don't see people adding 30 or more posters or guide images in a world. Advertisement posters make the most sense.
• For art exhibitions, images are usually baked into textures rather than dynamically loaded so it's not a place i see it used. It's also very rare for a world to showcase 30+ images at these venues too.
• If guides require 30+ images, that may be excessive, especially since each 2K image could consume ~15MB of VRAM, totalling to about ~440MB for 30 images. This would make the world unable to work on some systems because a large portion of the worlds VRAM is tied to pictures alone. Going to these worlds in groups would be a little silly too.
________________________________________
User Experience and how it effects the gameplay and experience of each individual.
• Does the user need to wait in a loading screen?
• Does delayed loading affect gameplay or immersion?
• If the content is purely promotional (ads/posters), waiting should be of no concern as advertisements do not add to the user experience.
________________________________________
Security and Abuse
• Harsher limits make attacks harder, since delayed feedback discourages brute force attempts.
• Removing or relaxing limits could make cheating or exploit attempts easier, as attackers would get faster responses.
• Reduces the likelihood that people use VRChat as a farm to put strain on various domains.
I believe this change was originally implemented because websites did not like VRChat constantly accessing them for data at uncapped rates.
________________________________________
Some final questions i'd like to ask.
• What tangible benefits would users see if the cooldown or limits were removed?
• How does this change improve the system beyond developer convenience?
Currently its difficult to see what benefit this adds to the user aside from making poster and advertisement spam worse and making abuse more rampant.
Invertex
This would be great to see, and I also have a feature request that would help this issue out a lot here:
If the content was cached there wouldn't be a reason for the cooldown after a user already encountered those URLs. This would make using external media and dynamic content a lot more reasonable.
nuruwo
I spoke with the poster, chiugame, and clarified the situation.
Premises:
- Currently, there is a 5-second limit on loading assets (String, Image, Video) per world.
- VRChat imposes this limit for security reasons (mainly to prevent data from being sent externally).
Challenges:
- In worlds with multiple loading assets, the 5-second limit conflicts, so world creators are forced to take many measures, such as prioritizing the loading order for each asset due to time and space constraints, or intentionally adding delays, which places a burden on world and asset creators.
Solution:
- If the 5-second limit is set on a domain (second-level of example.com) rather than on a world-by-world basis, conflicts can be avoided, as each asset usually has a different domain.
Concerns:
- Due to the security reasons stated above, subdomains (*.example.com) should not be allowed, as they can be mass-produced. If they are second-level (example.com), each domain requires a fee to acquire, reducing the risk of spam and data transmission.
( I've corrected the domain of the example and reposted it. )
桜鞠ステ♪
5秒じゃなくてもホワイトリストのようなリストにあるものはそれぞれでカウントして貰えたらとても素敵ですね！
Docteh
> In extreme cases, if just one asset tries to load 30 images at once,
i think vrc wants to avoid world creators wanting to do stuff like that
chiugame
Docteh Thank you for your comment.
Yes, I agree that VRChat would want to avoid that.
However, that concern is unrelated to this particular Canny request.
This proposal is simply asking for the 5-second restriction to be applied per domain,
and it would not affect how these systems are used or their overall security.
In addition, there is no practical way for world creators to know how a commercially sold asset is implemented before purchasing it.
As a result, it’s possible for important parts of a world to remain in a waiting state for an extended period of time, unintentionally, after placing such assets.
syncpulse
Docteh default vrchat home downloads approx 40 images immediately upon join
srckat
I agree that the 5 second restriction is annoying, but I want to bring up that making it per domain means that one creator could potentially create 50+ subdomains and poll them all at the same time, which could cause a lot of potential issues. Not that I don't agree, just adding on to this.
chiugame
srckat Thank you for your comment!
I believe it would be possible to handle this in the same way as the current whitelist system, where subdomains are included.
For example, entries like *.github.io are already allowed in the whitelist,
so I don’t think this change would cause any issues.
Theoretically, one could obtain 50 or more separate domains to achieve the same effect,
but that would be highly impractical in reality.
srckat
chiugame So basically, that would mean that enabling untrusted URLs
could
cause a lot of bandwidth to be used randomly. I'm not sure if they want that.