[VRChat Request] Regarding local persistence

[dtupper]

Hello VRCX!

We see that you're planning on implementing a form of persistence that relies on using Udon remote strings to access local URLs.

Being able to access local URLs isn't good security practice, and generally, we don't want to allow this. In an upcoming security update, we had already planned to block most if not all bogon IP networks.

But then, we learned about this PR. This security change would break VRCX's implementation in that PR. We're also aware that'd it break some other systems, like Varneon's Udonity.

However, we know persistence is really useful and highly desired. As it happens, a couple of types of persistence are coming very soon, including a form of persistence that would implement the features this PR provides. We're looking at 1.5 to 3 months, maybe. These features are yet to be announced so timelines can still move. You're getting a bit of a preview here.

We are concerned that if the VRCX form of persistence becomes popular (as it probably would be, it's pretty convenient), many worlds will then be affected by the security changes. Those worlds will break when we make this change, affecting a large number of users and causing them to lose data. Furthermore, users may accrue large amounts of VRCX-brand local persistence data that won't migrate to the native implementation. As this would be pretty terrible for a user to experience, we wanted to contact you as soon as we learned about this.

As such, we'd like to ask you to refrain from implementing this feature as a baseline feature. We'd also request that you discourage world developers from implementing it and then encouraging users to install unstable versions of VRCX, as shown below:

I'll be glad to answer questions on this issue if needed! You can also contact me on Discord. My username is tupper.

Thank you!

[Myrkie]

well that sucks, at-least its being added officially in the future in another form so not all of this work will go to waste.

[SalbugVR]

Appreciate the heads up on this~

[clienthax]

@dtupper If this is planned to be restricted, can you please make sure localhost is only restricted in live builds and that it remains available during editor / local testing? Testing data loading within worlds with vrcjson / string loading / etc will become more troublesome without localhost access.

[dtupper]

@dtupper If this is planned to be restricted, can you please make sure localhost is only restricted in live builds and that it remains available during editor / local testing? Testing data loading within worlds with vrcjson / string loading / etc will become more troublesome without localhost access.

Yep, the bogon block would not be in effect for local test worlds and editor.

[GroovyTeacup]

Hello VRChat and @dtupper!

Good to hear from you! Very cool that we're both on the world persistence bandwagon! I've been hammering away at our own version over here and was actually pretty close to finishing it up and pushing it to stable - funny timing, right?

Look, I'm no VRChat developer - I don't know the ins and outs of your systems, teams, project management/structure, or any other various difficulties you may be restricted by, and I'm not here to pretend I do. So please take everything I say with a grain of salt - I'm coming from a place of wanting to help and empower content creators to do things they are not able to do, not cause un-necessary drama.

Firstly, it's great that you reached out to us about this. You could've just shrugged and moved on with your internal planning, but you didn't. I can at least respect that. Pretty cool of you.

Anyway, addressing the big pink elephant in the room! When you say that accessing local URLs isn't good security practice, can you help us understand why, from your perspective? I'm certainly no security expert; but security isn't always a black-and-white situtation. The way you've presented the issue feels a bit binary - either we implement our feature and break stuff when you update your security, or we don't implement it at all and twiddle our thumbs waiting for a native solution. What about a middle road? Can we adapt our feature to match your security updates, or figure out a way to smoothly transition when the time comes? If you were willing, potential security concerns around the feature could be mitigated. What's your stance on this? Why and why not?

You've acknowledged that world persistence is both "useful" and "desired", but, no offense, it's still missing from VRChat after 2 years from its original teaser back in mid-2021. It feels like we've been waiting for the Christmas that never comes. This is not just something that we want, it's a persistent desire from creators in general. It's one of the highest rated feature requests, especially in the context of world creation, at least on canny. Giving creators more avenues to explore their creativity, as I see it, can only benefit the game in the long run.

You've also mentioned that you've got your own persistence in the works, which is super exciting! I have to say though, your timelines are a bit... blurry. I've invested 2 weeks of my own time into this so please understand that using my work as an example of a 'preview' of your own system doesn't exactly soothe my concerns surrounding when this feature will arrive, or what it'll be like. Some extra details or a chance to collaborate on the issue would go a very long way.

We totally get your concern about worlds breaking due to the upcoming security update - nobody wants that, especially if it causes real issues and anguish for the end-user. But you've got to admit, it's a bit ironic that in the same breath, you're acknowledging how popular the persistence feature could be, while also discouraging it. Can't we find a way to make both work in the meantime and make sure any future transition process is as smooth as possible?

Lastly, I'd like to gently push back on your bolded request for us to refrain from implementing our feature and even actively discourage creators from using it. We're not here to cause problems, but we are here to provide value to the community. We're more than happy to play by the rules, but we'd very much appreciate if those rules included some wiggle room for third-party innovation, and not thinly-veiled demands to cease development on things.

I'm more than willing to have open dialogue about this with you and everyone else here, on Github, and figure out something that works for everyone. If anyone else has anything to say, concerns or otherwise, I very much encourage you to voice your opinion on the subject; More perspectives is never a bad thing, as long as discourse is kept civil.

Let's work together and come to a proper solution on this! We're all after the same thing in the end - a better VRChat experience.

Cheers, Teacup

[natarii]

Teacup asked for other perspectives, so here's one :) I am not involved in the VRCX project, but I'm a happy user. I've also had persistent storage for worlds on my wishlist for quite a while, so VRCX coming up with a standard method for this is of interest to me, and I was planning to implement it in the next update to my world.

To begin, I think dtupper establishing communication here is overall a good thing. Having any kind of dialogue about this is probably better than none at all, regardless of the outcome. There are a few things that stood out to me in the original post that I'd like to comment on:

We're looking at 1.5 to 3 months, maybe.

I understand you can't spill the beans too much regarding upcoming features, but hearing this vague timeframe after a third party has already implemented it is difficult to act on. VRChat doesn't have a good track record here either - a reply from staff on the Canny post for this very feature states it is "planned for this year [2021]". Maybe things would've gone differently if the community knew this feature was actually coming soon. This is probably something that can be improved upon in future communication, to help avoid getting in situations like this.

Those worlds will break when we make this change

Surely any world that uses VRCX persistent storage as a prominent feature is going to have error handling to fail gracefully for users who don't have VRCX, are using Quest native VRChat, have untrusted URLs disabled, etc. So even if loading local resources suddenly breaks overnight, it shouldn't cause any undue problems other than the save/load mechanism not working. VRChat could also provide a timeframe for when local requests would start being blocked, in order to give creators who made use of this system some time to prepare/migrate.

Furthermore, users may accrue large amounts of VRCX-brand local persistence data that won't migrate to the native implementation. As this would be pretty terrible for a user to experience, we wanted to contact you as soon as we learned about this.

Given the state of current-day VRChat without VRCX, where there is no persistence at all (aside from a few hacky things using remote servers or copy/pasted strings), I would hardly call this "terrible". Additionally, previous VRChat updates have broken or reset core client settings and it didn't seem like that was considered much of a problem, so I'm confused by the sudden concern about it. This doesn't seem like a big problem to me.

Finally, I too find the sudden "ask" from VRChat head of community to not just alter or reconsider, but to refrain entirely from releasing a feature (which in my understanding does not run afoul of any of VRChat's terms) to be somewhat alarming, albeit not exactly surprising given VRChat's prior handling of similar situations.

Personally, I hope the VRCX developers release this feature in the next stable build, and that we continue to see it adopted by world creators. It would not be the first or last time that a third-party tool or integration eventually got broken due to an update, but it seems to be working well currently, so let's make use of it in the interim. And in the meantime before a first-party solution is available, it'd be great to see cooperation from VRChat staff to limit potential problems caused for this or any other well-meaning tool/service. Like please please please make the untrusted URL system less black-and-white, a simple prompt before allowing the request would alleviate so many security concerns in the first place :(

[knah]

@dtupper assuming the main concern here is actually an upcoming security fix potentially affecting this feature, there's a very simple common ground to be found: allow a small subset of ports on localhost to be used for web requests, say 15000-15010 (random range, up for choosing), including for users who have "Untrusted URLs" disallowed. The port range could also be a config option that tools interested in such usage could auto-set in config.json.
This allows the security fix to address potential issues with access to local or private networks, while at the same time allowing tools such as VRCX world persistence or Udonity to keep working. The general approach of feeding data from a local web server could still be highly useful for other use cases too, until another kind of connectivity, i.e. world OSC, becomes available.

With such a compromise, migration of data from VRCX-provided persistence to any official solution would not be an issue, as worlds would be free to move the data from one system to another. Additionally, if the VRChat's solution would use local jsons like avatar parameter storage does, VRCX could migrate data automatically.

PS: It would be a shame to see VRChat kill yet another community effort to go above and beyond what base platform provides.

[dtupper]

There's a huge amount of statements, questions, and requests in your posts. I'll do my best to aggregate and respond to them. Forgive me if I skip your specific point, but I can't spend all day writing novel-length responses!

@GroovyTeacup your post in particular has several addressables I'll use.

Anyway, addressing the big pink elephant in the room! When you say that accessing local URLs isn't good security practice, can you help us understand why, from your perspective? I'm certainly no security expert; but security isn't always a black-and-white situtation.

Sure thing. I am also not a security expert, but given a few minutes of searching, I found some demonstrable examples in the wild we want to avoid and confirmed that these are the class of exploits we're concerned about with our Security team. Notably, a few years back, a TrendMicro bug permitted ACE with a GET request. There's also a lot of cases where routers have vulnerabilities along these lines, like this one with Netgear routers and this more recent one with Buffalo routers. Admittedly, the last two are arguments against local network access rather than localhost access, but it's still a tick against it in our book.

I hope these cases (and all the others out there) provide the answer: we're concerned about keeping our users safe from remote code/command execution due to local device access via HTTP.

You've acknowledged that world persistence is both "useful" and "desired", but, no offense, it's still missing from VRChat after 2 years from its original teaser back in mid-2021. It feels like we've been waiting for the Christmas that never comes.

Absolutely. Trust me, more than anyone else, I know how long it takes VRChat to implement things. Down to the count of days, in some cases... Anyhow. Part of my job is to represent the community's voice at VRChat's table, and I think several producers and engineers want to throttle me after I ask "so what's up with persistence? avatar scaling? world rules? 🙃" for the 27th time this week.

With that in mind, rest assured that we know how much people want persistence, and we've been working on it for quite a bit. It's going to be ready quite soon.

I'll admit that the "i want it now!!!" feeling is something I share with you. However, I think that after ~2+ years, a few extra months isn't going to be pivotal to world development.

I've invested 2 weeks of my own time into this so please understand that using my work as an example of a 'preview' of your own system doesn't exactly soothe my concerns surrounding when this feature will arrive, or what it'll be like.

I understand completely. We've invested quite a lot of development time ourselves into ensuring VRChat remains safe for all while delivering features (eventually... 😅) that users want, so I completely get that pain.

Some extra details or a chance to collaborate on the issue would go a very long way.

Let me offer some clarifications and compromises that might help out here.

First, we will not deploy the security change until after "player persistence" is in Live. "Player persistence" is what we're calling data storage sectioned off per world ID, which would feature-match VRCX's implementation from what I'm seeing. As previously noted, this feature is expected to hit release within 1.5 to 3 months.

Second, we will consider adding a launch option that will turn off the bogon check for either a pre-defined set of whitelisted ports or a list of user-defined ports. There are no guarantees here, but the Security team has stated they think that's a possibility.

Third, we will consider having an always-on whitelisted set of ports. This one's a bit more challenging of a sell, though.

Please note the emphasis on the word "consider" in the second and third items. These are not guarantees!

There are a few caveats I want you to keep in mind:

We're hesitant to add more launch options in general. Not only do launch options prevent the majority of our users from accessing that flag (Quest can't use launch flags, ofc), but we are also concerned that adding launch options may encourage VRCX to implement instructions or directly launch VRChat with the debug launch option on by default, which... defeats the security without direct user consent. We're kinda not OK with that? The flag is likely going to be named --insecure-bogon-network-access or something along those lines, and typing that flag in yourself is kind of a "hey, we hope you know what you're doing" check.

Additionally, on that note, we don't feel great about providing users a way to "shoot themselves in the foot", as it were. A launch option to undo a security change is not something we're OK with, and is part of our hesitance here.

Next, we're still worried about the weird user experience of VRCX getting a new feature, then VRChat implementing a version soon after, and then also breaking VRCX's in the same swoop. That looks hostile where no hostility exists. To be blunt, both persistence and this security change were already on the way. Nothing I'm telling you is new changes or features, but they are new for us to announce.

In other words, it will look as if VRChat pulled the rug out from under VRCX fresh after it launched a new feature, which is not what we want to do and is not representative of reality. This is why we are telling you in no uncertain terms that we have changes in the pipe that will break this feature. We let you know as soon as we found out about it. If we had known sooner, we would have told you sooner.

Finally, a big concern with the VRCX implementation is that it may cause a split in user behavior, content compatibility, and the community. Keep in mind, more than half of our users cannot use VRCX on their local device, which means that they won't be able to use that content.

(selfishly, I also cannot use this, because I don't give third-party applications my VRChat credentials. 🥲)

I hope this makes things a bit more clear, and I hope the compromises help make this transition as painless as possible for end users.

[ReversedField]

(selfishly, I also cannot use this, because I don't give third-party applications my VRChat credentials. 🥲)

https://feedback.vrchat.com/feature-requests/p/provide-an-authenticationauthorization-model-for-third-party-api-integrations Just wanted to maybe bump a canny

[BocuD]

Me and a few others are working on a large world that already has persistance, and we have been relying on an avatar parameter based saving system for about a year and a half now. It provides arguably more flexibility than both the system that was proposed by VRCX and what seems to be coming to VRChat now, in the sense that it allows cross world saving. We recently discovered some new workarounds to be able to store a lot more data using that method, but this system is still very maintenance heavy (it likes to break with VRChat updates and is inherently less stable because we literally write binary data through player velocity). I was wondering if you're able to give us any information about this being / becoming a thing on this or some other native VRChat persistence system, as continuing to develop our existing save system might not be worth the time if it fits our needs as well :) Without support for cross world saving (from the same author of course) this system would basically not be an option for us. Don't get me wrong, i'm extremely happy that there finally is a word out about any progress towards properly supported persistance at all, as it will still let me do super cool stuff in other projects! But as the main project/world i (and quite a large team actually) work on, this is very big. Current options we're discussing on our team are not using this native system at all, or having the native persistance system act as the main save method, and then using avatar parameter based saving to transfer data between worlds, but for obvious reasons i would rather avoid this 😅

[TanukiPenny]

@BocuD For accessing data from other worlds, it seems like this was added in a recent pull request merged in. Not sure if it's done but it at least seems to be a planned thing. See pull request https://github.com/vrcx-team/VRCX/pull/558

Also if I misunderstood what you where asking for just ignore me.

[GroovyTeacup]

@dtupper Thank you for your response and understanding. I appreciate the extra details and consideration given. I personally agree with you that a parameter to essentially disable a security feature would be a bit odd; I could easily see an app or something telling all of their users "just turn this off It doesn't matter" and suddenly it doesn't mean anything. ...Kind of like the current implementation of untrusted urls.

Even if just a small port range that was researched a little bit beforehand to make sure it's not being actively used by any other known public products, something like that being whitelisted for, perhaps, just localhost, would be useful for tools wanting to make use of it while also minimizing any potential attack vectors by malicious worlds. Even if it's not specifically used for world persistence, having a little support like that for other developers would mean a lot to them.

---

@BocuD I assume you specifically mean cross world saving? The current system allows for worlds to access another world's data but only if the world in question allows it to prevent abuse; I didn't think about grouping that permission under an an author ID though, that could be a nice way to do it. If you'd like to request anything specific, feel free to reach out to me on discord @ Teacup#1442 or the VRCX server and we can talk about implementation.

[BocuD]

@GroovyTeacup @PennyBunny I was actually mainly asking @dtupper about this, i suppose i should have made that clear 😅 I was not aware that VRCX added this functionality. Thats good to know for sure. I might DM you about that at some point still yeah because implementing the VRCX system would be a good usability improvement we can do for PC users specifically.

[dtupper]

@PennyBunny You're welcome, of course! As I noted, I would like to remind you that the port range and launch option is not a guarantee; they have downsides that I listed (and a few more).

The delay until persistence launches, though, is a thing we're doing, along with the caution and our worries about what would happen if VRCX launches this feature and it becomes popular and then gets broken by the upcoming change.

[DarthShader]

It is definitely good security practice to prevent access to potentially insecure HTTP server software running on users' local machines/networks, and it makes logical sense to preemptively unify persistence with a first-party solution. However, neither of these points are justification for completely blocking localhost HTTP server access. As suggested by others, a set of VRChat-specific whitelisted ports would be more than enough to prevent tampering of local HTTP server software; there is no reason not to go forward with this approach.

As exemplified by creations like Udonity, an in-house data storage/persistence solution for VRChat worlds is no real argument for limiting web connectivity at all. Like with MIDI and OSC, creators will find emergent possibilities and make cool things even if you don't give them the proper tools to do so. If you do not leave localhost access open, creators are still at liberty to parse output logs for world data egress and pipe data back to worlds through MIDI. Funnily enough, even with the web request "String Loading" system recently added to Udon, it is still more efficient to use this method to make properly dynamically constructed web requests and perform web requests without the ridiculous 5 second timeout.

Your continued artificial and arbitrary restrictions to VRChat content in the name of security are insulting to creators who just want basic infrastructure. I hope you understand the implications of this specific technical choice and make the correct design decision. I also hope you realize how such seemingly small changes over the years has made VRChat look antagonistic towards advanced creators.

[TanukiPenny]

It's a little off topic, but the 5 second rate limiting can be very annoying. Maybe VRChat could consider using a token system where you start off with an amount and you can use them as fast as you want, but they only replenish 1 every 5 seconds. This would help lots of systems that need more requests but not constantly. It would not solve everyone's issues, but it could mitigate them.

[BocuD]

As someone who usually praises VRChat for the freedom and creativity it allows, i cannot agree with you (@DarthShader) more. Some of these decisions are very strange and are holding back VRChat just that tiniest bit from being an ideal platform for creators. In 99% of cases we end up building hacky solutions on top of the limitations that are usually quite artificial, and while this can be fun to work around in its own way, it shouldn't be needed (think AvatarImageReader, NUSaveState, and the system VRCX is now proposing just to name a few). Many of these end up being replaced years later by a native solution despite a native solution requiring very little actual development time (especially in comparison to the workaround systems) to be implemented.

[nyakowint]

(selfishly, I also cannot use this, because I don't give third-party applications my VRChat credentials. 🥲)

@dtupper speaking of this, any uhh... rough timeframe (at least) of when/how OAuth(2) will actually be implemented in a form accessible to third-party applications and not just VRChat partners? Currently I observed Canny using it, and I think the avatar makers also do (didn't double check this, but makes sense for them to)

[dark-swordsman]

@dtupper 👀

I know you said 1.5-3 months and that it can still change, but it has been 3 months. I also just noticed that LS Media supports this now as of the past couple weeks AFAIK. So... you might want to release that feature quick before more people notice.

I was mind-blown that LS Media supported it, and am now considering using VRCX's implementation in my worlds. With no solid guarantee or view of the state of these features, we can only guess, and I can only use VRCX's implementation.

Also, please do not block local addresses outright and at least leave an option. There are many cool things to be used with local IPs.

[Happyrobot33]

Just want to pile on here even though my comment probably wont be read, following this would set a bad precedent. Imagine if this same kind of response was done when gogoloco added scaling into its broke version, or when udonsharp was being developed, or when VRCFury was being made. I could go on and on about public projects that people have created just because the VRC team never gets around to them.

And the security issues mentioned doesnt mean anything since its still very easy to track users through things like video links at the minimum. Theoretically, you could literally make a botnet world using video URLs, String loading URLs, Image loading URLs, etc, and all youd need is a HQ webserver for everyone to talk to. And it also brings into question, did the engineers working on it not think about this abuse vector when it was being developed?

This request would be great if we could trust your timelines on things at all. Its just not feasible for pretty much anyone in the creator space at the moment to do that, given the track record the team has established. I mean I'll just point out here that you mentioned 1-3 months as of this git issue, and its coming up on 4 months since you posted this. I know you mentioned "maybe", but I also believe that persistence hasnt been shown off in any blog posts yet to begin with, so functionally to me and pretty much everyone else it doesnt exist

Im sorry if this comment seems negative, its just frustrating to continually see issues that should tops take a few days to fix sit there for eternity, and systems with minor issues or usability issues not be touched anymore after a few months of being implemented, and im sure im not alone in this view

[dark-swordsman]

I think you're good @Happyrobot33.

I think I understand now why a lot of people have been upset with VRChat for a very long time relating to features not being released.

When EAC happened, the team did a really good job at communicating constantly and doing lots of updates. But at this point it feels like everything has slowed down. I'm pretty sure the second to last developer update barely had anything in it.

I totally understand that VRChat can't talk about certain things in too much detail. I also completely understand project priority and scope, where it's kind of impossible to work on even small things due to the requirements of other tasks.

But it's really things like this that grind my gears. We have a really useful feature that is actually being implemented by another software. Yet VRChat doesn't want them to implement it due to "security" and the possibility of their own implementation.

That's fine and all, but it has to come with a hard date. This is one of those times where I genuinely don't understand why they don't have it yet. It's writing JSON to a file, filtered through an API. How hard can it be that it would take more than 4 months to work on?

I am deathly curious about the internal processes at VRChat and why simple things like this seem to take forever to implement. They even teased imposters nearly half a year ago, which I think will be a game changer to making instances performant, yet that's also been non-existent for months. I understand that sometimes it's difficult to scale a company and get more people to work on features, and like I said certain tasks taking priority. But recently it feels like VRChat has fallen radio silent again.

Edit: It feels like a constant cycle of: "Hey guys! Here's this really cool feature that we're working on right now!" And then they don't talk about it ever again.

Like I said, I understand things take time and you can't build Rome in a day. But for the love of God, stop saying you'll develop things when you don't. Or at least keep an update on it, even if it's to say, "Still in progress!"

It would be great if VR chat had some sort of road map or Trello board showing all their announced features that they're working on, with some sort of check date that confirms the state of the task. This way, if something is delayed or taking time, it can be confirmed rather than it sitting in limbo forever.

[Happyrobot33]

I think you're good @Happyrobot33.

I think I understand now why a lot of people have been upset with VRChat for a very long time relating to features not being released.

When EAC happened, the team did a really good job at communicating constantly and doing lots of updates. But at this point it feels like everything has slowed down. I'm pretty sure the second to last developer update barely had anything in it.

I totally understand that VRChat can't talk about certain things in too much detail. I also completely understand project priority and scope, where it's kind of impossible to work on even small things due to the requirements of other tasks.

But it's really things like this that grind my gears. We have a really useful feature that is actually being implemented by another software. Yet VRChat doesn't want them to implement it due to "security" and the possibility of their own implementation.

That's fine and all, but it has to come with a hard date. This is one of those times where I genuinely don't understand why they don't have it yet. It's writing JSON to a file, filtered through an API. How hard can it be that it would take more than 4 months to work on?

I am deathly curious about the internal processes at VRChat and why simple things like this seem to take forever to implement. They even teased imposters nearly half a year ago, which I think will be a game changer to making instances performant, yet that's also been non-existent for months. I understand that sometimes it's difficult to scale a company and get more people to work on features, and like I said certain tasks taking priority. But recently it feels like VRChat has fallen radio silent again.

I don't want to derail the conversation but tack on to that last paragraph udon UI which when last shown off looked finished

[dtupper]

The very short version of my response is that both Mobile and Creator Economy are both very, very important to VRChat, and as such, are where most of our resources are at the moment. In addition, development on Persistence has not stopped, but it is slower than expected. That is due in part to our wish to create a durable, holistic system rather than just a simple data store.

While we (clearly) busted our initial estimate of 1-3 months for persistence, that's because priorities changed during that 1-3 month time period... as they often do in gamedev. So, things got pushed back. This is why we -- and basically everyone in software development -- simply don't give feature timelines. They always get moved. Giving dates is a gamble you rarely come out on top on.

While I'd love to give you a running, up-to-date tally of our priorities, that's not an expectation I want to establish for future features, nor do I think it's a reasonable expectation.

We've discussed a public Trello before. While it isn't off the table, I don't think we ever wanted to put dates on it -- only current status. I struggle to think of a company or product of our size that puts dates on something like that, but glad to be proven wrong. 🤔

I know waiting for long-awaited features is a huge pain. Persistence, in particular, is something I desperately want because it'll enable a huge class of content that simply doesn't exist in VRChat yet. (Preaching to the choir, I know.)

As such, our original ask remains the same, as we wish to close the security gap that allowing localhost access opens.

[dark-swordsman]

That is due in part to our wish to create a durable, holistic system rather than just a simple data store.

But why? This is also another problem I take issue with. I understand the desire to create robust solutions. But how is a JSON file with fields not robust enough? Why can't we just have a JSON local store for now, and then you can update the system later if you want to add more advanced functionality to it? Y'all seem to do this with a lot of features.

While it isn't off the table, I don't think we ever wanted to put dates on it -- only current status.

That's completely fine! Like I said, the problem is when you guys announce features that, despite being WIP, look basically finished, and then go radio-silent on them for 4+ months. This is especially true when you yourself said you pretty much only announce things in the dev blogs when they're within 2-3 months from being released.

As such, our original ask remains the same, as we wish to close the security gap that allowing localhost access opens.

I still completely disagree with this decision. At least make it off by default and allow users to override it. I use localhost/local network for a lot of things, namely to watch local media in VR. I also know other people that use local addresses for other useful things in VRChat.

This is really the first time I've heard of a context of local IPs being bad practice, especially since the idea of IoT/home automation relies on this functionality.

Edit: I will also add: I find it strange that world persistence isn't prioritized by VRChat as a business. It means people will likely spend more time in worlds to grind them and progress. Creators will be incentivized to make more immersive and engaging experiences that keep the users there for longer, and that's pretty much only a net positive for VRChat to increase user count, user retention, and potential revenue, no?

[Happyrobot33]

even better idea when it comes to local IPs: Implement something like was recently implemented with OSCQuery where programs can request a port to communicate with VRC over

From what I can tell this would completely solve your concerns. String loading wouldnt be able to arbitrarily exfiltrate requests to any random local IP, and programs like VRCX can say "Hey VRC can you give me something to communicate over" and then allow just that port to be open for URL requests. Ofcourse with a caveat that ideally it should be a port range specifiable by programs unless the dev team would want to go through the effort of allowing udon to see ones open