euan Is there the possibility that this particular check can be relaxed just for worlds for now? While I understand the difficulties of tracker music, so long as Udon exists, surely there will always be ways to break the audio system pretty badly (unless there's a concern about true exploits I'm unaware of).

euan: what do you imply under "security ramifications"? None of the tracker modules can be used to transport or execute arbitrary code, as they're all limited by the interpreter's instructions, which unity ships with--a cut down fmod interpreter that is sufficient enough to validate the files or reject evaluation at runtime.

Not exactly a good validator if it fails to scan formats that exist for over 20 years by now.

And it isn't the first time you fellas kill a feature built into unity under some vague pretense or with a lazy implementation. Not looking good.

Given that this issue's been around for almost a year by now, when can we expect it to be resolved, if you only now acknowledge its existence?

alareis: A few years ago there was a security exploit involving one of the tracker modules which required us to contact unity to make engine changes to fix. You may assume fmod cannot have / facilitate exploits but it can, even if not directly apparent, though we can hope the one discovered a few years ago was the only one.

In our analytics the usage of tracker modules is incredibly rare on avatars, combined with the concern over exploits put it quite low on the list of priorities. This issue has been responded to now as worlds now go through server-side processing, although also rarely used it affects more content comparatively raising the priority. It has also gotten me looking into the complexity of the task again to scope out how much work is needed to add in proper validation so it can be properly prioritised.

euan: It no doubt can have vulnerabilities, I just assume that none of it is within the actual security of the application--i.e. no ACE, only audio thread issues. Either way, have they patched it on your request, then?

Yet it's a part of the stack of features unity provides and you up until some time ago. While yes, it's rarely used, it nevertheless was used. Same with object destruction, same with clothsim. One at least was killed off with a word of acknowledgement, the other two have been non-functional for close to a year with no news.

I understand it's hard to estimate task time for a full audit of an interpreter when it's low priority, but not having any time frame at all is frankly not helping it. The lack of any clear timeline is frustrating, since issues like these completely stall the progress on anything that was in the works. If it's going to spend another year or more in backlog limbo, you might as well discontinue the support for it entirely, as it effectively is now.

alareis: It involved the actual security of the application, though we have no evidence that it was exploited in the wild and it required specific conditions. Given your original canny was related to usage on avatars I feel I also should note the existence of avatar crashers which use bugs in unity's general audio system to crash the client, this is also something we very much want to combat and which tracker modules widen the attack surface of.

Just because unity supports features doesn't mean we explicitly support them, unity allows for very wide range of things but those things can lead to undesired behaviour in various forms that don't become apparent until a good amount of time has passed. Adding to this before server side processing was introduced there would have been no effective way to block certain functionality if we wanted or needed to. This gets onto a complex topic of what is supported and what is not supported, suffice to say it's not really realistic to say we will never have to adjust what's allowed as time goes on, this for multitudes of reasons. For object destruction via particle systems on avatars we took a path which which impacted things the least while preventing the behaviour from breaking various systems. For cloth I'm unsure what you are talking about, unity's cloth is a brittle system though.

In terms of timeline unfortunately unless something is actively being worked on and has the end in sight giving an estimated timeline can often invite disappointment of it not being met because priorities will always shift and there's limited engineering time available, especially if it gets into a specialised area.

euan: still having a hard time finding an issue that you are talking about. To clarify, I don't consider an unhandled or poorly handled behaviour that leads to a crash to be a security violation, only a stability issue. Security covers data exfil, isolation breaching, or arbitrary code execution. Yes, I'm vaguely familiar with audio system hijinx with avatars. Though at that point you'd have to swap out that subsystem for something that rejects samples outside Nyquist window at runtime. Creating funky PCM clips is marginally easier than creating funky modules, at least in the formats I'm familiar with.

Going by that logic, we can't expect any of the basic things provided to work--down to mesh renderers--though. I get it, it's a developing application with things changing internally, and sometimes issues arise. The issue I have is that things that have been available to us--even if implicitly--get integrated in our workflows, and then suddenly vanish or are disabled, with no foreword or acknowledgement. Going by those examples, instead of simply disabling these features: provide a deterministic replacement component for object destruction; provide a replacement tracker module interpreter in this case. Sure, the latter is a tall ask, but you get the idea.

Cloth component issue I'm talking about is covered here: https://feedback.vrchat.com/bug-reports/p/cloth-component-refreshes-on-every-frame-during-synced-rescale-globally-causing

And yet it can provide a form of a feedback, delay the "is it done yet" nagging. I'd say it's fair to claim that we don't expect you to be on time with features in most cases, especially when it comes to more niche things like this. It's not just a curiosity--it helps us plan ahead as well. Like in this case: it's looking pretty grim, so the best course of action is to either abandon related projects, or to implement them in roundabout ways.

alareis: I feel you misunderstood my previous message

> I just assume that none of it is within the actual security of the application--i.e. no ACE, only audio thread issues

I responded directly saying the opposite of this

> It involved the actual security of the application, though we have no evidence that it was exploited in the wild and it required specific conditions

To be clear it would have allowed for RCE

> Going by that logic, we can't expect any of the basic things provided to work--down to mesh renderers--though

That is a massive leap, from something that's used on a handful of avatars and not mentioned as supported anywhere in our docs to something that's there on the vast majority of avatars and we explicitly document support for. In terms of messaging when it affects so few people there's not an appropriate place to communicate that currently, given the check is server side it's not really appropriate for it to go in the client changelogs either. For messaging around failures with the server side processing we want to improve that however again engineering time is limited. And yeah for this case the comparatively easier route to support things would be implementing validation, there would be no way without significant engine changes to have a different interpreter.

Regarding the cloth issue from what I can see it's not a simple issue however only an issue on avatars which would be extremely in the category of very poor.

In the past we used to be more open with exact plans, this in almost all cases caused disappointment because of the shifting priorities and unexpected speed bumps, as a developer I can say it's not great for moral either. As for nagging that will occur no matter the setup. So generally to avoid disappointment only stuff closer to completion or stuff that's large and unlikely to be put on hold is given a timeline.

Given this conversation is getting off topic from the core issue at hand I will not be responding to this specific thread of questions again. I hope my responses have useful.

euan: yeah, no, I didn't misunderstand it. RCE in a subsystem that doesn't interface with network subsystem and simply reads notes with modifiers is one hat trick, especially the "remote" part. You'd think something like that would be documented in at least one of the vulnerability databases, given how old that fmod module is, or at least be known to . Maybe you should file one, seeing how it affects literally everyone using unity with that claim.

Is it a massive leap? You do support mesh renderers, just like you did support audiosource. Part of the latter stopped working. You did support trail renderers, part of it stopped working. How many instances of UGC use a particular system should have no bearing on this. But instead of fixing it, you just drop the support for things because "eh, who cares". Again, this leads to the possibility of you dropping anything supported the same way, be it something obscure or common. Like mesh renderers. We can't be sure you won't, given the track record.

How is there no appropriate place to communicate this, you have patch notes! You have a forum with development outlines. You create your own communication channels. Given that server-side checks are affecting the behaviour of the client, it arguably should be a part of patch notes.

Cloth specifics is irrelevant to this, but your note on performance rank is confusing me. What does that have to do with creating a bug? Are you implying performance rank now affects how you fix bugs, in addition to how often something is used?

Well, it took some three messages to get it out of you: it effectively won't be fixed, sans some christmas miracle.

Oh, don't pull a tupper, never looks good on you. It's been on topic plenty, and only now we got somewhere. The implications for the rest in your responses leave more concern than help, though.