Must be able to deny access to "trusted URL"
Cymbidium
VRChat has a list of "trusted URL" and URLs on this list are automatically accessed.
For some time now, there has been a fear that these URLs could track us without our consent.
However, recently an unfamiliar url was added to the "list of VRChat's trusted URLs" and it appears that these URLs are actually capturing, tying, and recording our user identifiers, IP addresses, or both without our consent.
These require explicit consent, and the current inability to refuse them may violate the GDPR (The EU General Data Protection Regulation).
Even in regions not covered by the GDPR, there are certain people who do not trust these URLs, and therefore the option to reject some or all of them should be provided.
Thanks.
Log In
Reimajo
Allowing users to block whitelisted services would break functionality in a lot of worlds, sometimes even for other users.
The whitelisted services are carefully chosen to not allow creators to track users, so they should not be a concern. If you really don't like those services, simply add them to the
localhost
file of your PC to block them (but expect stuff to break as a result).If you cannot expect people to be able to access them by default, systems that rely on external configuration would just break.
The (better) alternative to this would be to simply make the users agree to either accept all used domains in a world before entering it for the first time or deny access to the world.
VKET and Furality both signed contracts with VRChat that should cover any concerns related to user tracking. If you don't visit those two events, you will be fine. The only thing needed here is that the Documentation is updated.
Cymbidium
> Allowing users to block whitelisted services would break functionality in a lot of worlds, sometimes even for other users.
Those who actually want to do the blocking should have no problem with it, as they want their functionality to be compromised. This ticket is to allow those who want to block to do so on VRChat.
And in what case would it impair the functionality of other users? At the very least, since most of the time these trusted URLs are only used to play videos, display images, display or use static strings, and are rarely used for anything other than tracking users, "blocking a trusted URL" is not likely to impair the functionality of other users.
> The whitelisted services are carefully designed to be used only for display or usage purposes.
We cannot trust them because we have confirmed that tracking is indeed taking place.
Please check the facts before making a statement.
Also, if these are indeed not being tracked, please urge vcapi, vket and vrchat officials to contact me and correct the facts.
However, even if the facts related to vket are denied, the request for this feature is not withdrawn because these tracking possibilities still exist.
> If you cannot expect people to be able to access them by default, systems that rely on external configuration would just break.
That is correct. That is the expected behavior. At the very least, we need to be able to block external configuration.
> The (better) alternative to this would be to simply make the users agree to either accept all used domains in a world before entering it for the first time or deny access to the world.
Why should we have to choose whether or not to join a world in order to choose not to access external sites?
As it stands, a world that relies on "untrusted external configurations" will no longer function.
As you can see, vrchat is not designed to build systems that depend on external configurations in the first place, so the alternative you propose is probably not a better alternative.
Still, since nothing is going wrong, it should be no problem to be able to block external configurations that are supposed to be trusted.
I can read from your text that you want to provide services using external configurations, but that is only allowed with the consent of the user.
At the very least, vket has entrusted the management of trusted URLs to a third party organization (vcapi) that seeks to track users. Once a user actually joins vket, they are tracked by the third-party organization.
Since this third-party organization is an organization that attempts to track users in various worlds, we cannot deny the possibility that these trusted URLs may be misused.
Reimajo
Cymbidium: Why do you insist on accusing VKET to track users? Where is your proof for this argument? Why would anyone go into a VKET world if they believe that VKET is an evil corporation that wants to track you (whatever that even means)? Why would VKET even need to do that through Udon, do you honestly believe that VRChat couldn't give them access to direct usage metrics instead of just whitelisting their domain for some image loading? Yes, that is what they do, loading images and other external content like audio/video into the world, or letting you open a website if you click something in it.
Everything you say here just sounds like a conspiracy theory that you are making up without proof and that has nothing to do with reality. You can go into any VKET world today and check for yourself what they are doing, e.g. using Wireshark or just reading the debug logs from VRChat. If any of that would be GDPR relevant, they'd put themselves in big trouble for no reason at all.
Do you know which corporation actually tracks users and is whitelisted for years? Youtube/Google. That is what you should worry about if you are so into that. Now go add them to your
localhost
file of Windows to block them and see how well that goes. They cannot track you anymore, and you cannot use the internet anymore. The deal with visiting a VRChat world is really just the same, with the difference that all we can do is pull an image or some text from a static URL of a provider that doesn't even allow us to get any information about who accessed it. You don't want that? You are free to not visit the world.The currently implemented features that use the whitelisted service don't allow more tracking than the video player since SDK2 did. Even less, because you cannot construct URLs at runtime anymore, so getting useful data out is pretty much impossible. And let's say they can, what exactly should they track here? Your display name and the world you are in? The VRChat API provides a way more powerful way to do that. And your display name is worth nothing.
I'm not sure how much you actually know about the possibilities in Udon today, but getting user-specific data out is close to impossible. If you are lucky, you might get the display name out in a crazy amount of time and millions of pre-baked URLs, but that wouldn't work with the whitelisted services anyway. And that is already all the user-specific data that you can access. Everything else, even your avatar, is well protected from Udon.
Loading external configurations into worlds is a well-known and legitimate use case that relies on whitelisted services. VRChat is based on Photon, so instead of a server that controls networking in Udon, a certain player (whoever is longest in an instance) is given the role of networking master. If that master doesn't share the same configuration, stuff will break for other players as well. The alternative to that is re-uploading your 200mb world any time you want to change something. To include all content into the build that is not needed most of the time, which increases the download size even more. In order to provide a usable world for all players, you sometimes need to agree on certain allowed methods.
Giving each user full control over what they can do in a world would ruin the experience for everyone. You might as well ask for a toggle to completely turn off Udon locally, or a toggle to not send your player position and audio to non-friends etc, all with the goal of more privacy. You'd end up with a completely unusable service in the end for everyone because nothing would work anymore.
Don't go into VKET / Furality worlds and you'll be "safe", or add those two domains to your
localhost
file to block them. It's really not that hard. Anyone can edit a text file. But don't make it even easier for random users who don't know what they are doing to block external traffic to sites that the world relies on. And please stop acting like you somehow own the worlds that you are visiting and the world owner has no right to load external content from a well-known provider like GitHub to provide a functioning experience for everyone, just because you are paranoid that this website could get your IP address (for whatever reason that is even a problem, as that request is unrelated to your VRChat username etc. and the world creator gets no access to it). VRChat isn't just about you.
>
As you can see, vrchat is not designed to build systems that depend on external configurations in the first place, so the alternative you propose is probably not a better alternative.
No, this is exactly why VRChat added string loading, to allow stuff like external configurations. To prevent that people must re-upload their world to change something.
Cymbidium
Reimajo:
First, though, why do you object to adding a means of denying access to whitelisted URLs to that extent?
These requests would add a means for those who wish to reject whitelisted URLs to do so, and would have little impact on those who do not wish to do so.
If you are not a member of the organization associated with a whitelisted URL, rest assured that you will be largely unaffected.
> Everything you say here just...
Yes, you can use the debug log to verify that you are sending user specific values to sm.vket.chat and vcap.vket.chat.
Try to join the world twice (or more) for each account with different users in cooperation with a friend, respectively. You will see that a different value is sent for each user and the same value for the same user.
Although wireshark is not used in this case, since access is done via https, the path is probably encrypted and cannot be confirmed by wireshark.
They record our information to save the user's world settings.
However, it is up to vket what they do with this recorded information, and often third party organizations cannot be trusted in how they handle this information. (e.g. use for marketing, use for another business, etc.)
> Do you know which corporation...
Yes, we will do so if necessary.
Currently I give youtube/google permission to track me, so I will not block to those sites.
However, I do not agree with vket or vcapi's privacy policy and would like to refuse.
I could realize that vket and vcapi are tracking me, but it would be a threat to users who, had they known, would have wanted to reject them.
Therefore, we need to provide a way to block those addresses on vrchat.
> The currently implemented...
Yes, so far the only components that can be tracked are the video player, image loader, and string loader.
We don't want to make this too public because it could be abused, but for example, if you have 64 different characters (a-z, A-Z, 0-9, _-) with 3 digits, you can send 18-bit URLs if you have at most 260,000 URLs. This is about 7 MB including the domain part. And this list of URLs can easily be generated programmatically and included in the source code.
Since the cooldown time of each component is 5 seconds separately, it is possible to send about 108 bits (13 bytes + 4 bits) in 6~7 seconds.
And there are several worlds where this is actually done, with vket actually sending 4-digit alphanumeric characters over 5 times.
This is as Docteh also mentioned in an earlier reply.
> And let's say they can, what...
Yes, at present my display name has little value.
But what if, for example, someone has a grudge against me and wants to get my IP address to launch an attack against me?
For that person, it may be worth paying to get it.
Since vcapi can link my username to my IP address, it is possible that someone could contact vcapi and get my IP address from my public username. (At least vcapi does not publish a privacy policy declaring the protection of such information).
Perhaps this will not happen in practice, but connecting to a third party organization in this way is risky.
According to the GDPR, if the third party is traceable (i.e., if access to the third party's site occurs), explicit consent is required.
And these will be a certain number of people in areas not covered by the GDPR who will also want to. Therefore, we believe such a feature is necessary.
Again, this is a feature that "those who wish to refuse" can refuse, and that will have little impact on those who do not wish to refuse.
> I'm not sure how much you actually...
I am not familiar with the internal implementation, but at least the aforementioned method can be done with untrusted URLs.
Or is it implemented in such a way that it is not possible to do this with whitelisted URLs? If so, please explain why different users accessing vket will automatically be directed to different unique URLs.
If you mean that organizations with whitelisted URLs do not do such things, then you are wrong, because they actually do.
> Loading external configurations...
Yes, that would probably be a legitimate use case.
I also don't believe that pastebin.com, etc. would target vrchat for tracking.
If vrchat implemented the ability to block individual URLs, most people would not block pastebin.com.
However, vket and others are organizations that have targeted vrchat for business, and access to those URLs should be carefully considered.
And to ensure a means to deny them, the feature we are talking about in this ticket is needed.
In addition, world authors do not need to make any specific implementation changes. For example, if a world has a room that only patreon can access, those who have agreed to access the URL can access the room, and those who do not agree can simply block it because it is unreadable.
If the specification is that access is only available if the owner of the instance agrees, vrchat can make a modification to allow individual access by those who agree.
If the feature in this ticket is implemented and the relevant issue arises, you may issue an individual feature request.
In addition, world authors do not need to make any specific implementation changes. For example, if a world has a room that only patreon can access, those who have agreed to access the URL can access the room, and those who do not agree can simply block it because it is unreadable.
It does not have to be available to all players. Users who want to block want to be "unavailable".
> Giving each user full control over...
This is a bit of a leap of logic, since the problem is unintentional tracking by an outside organization, not the other users.
Besides, as far as udon is concerned, smaller improvements can be made to protect privacy, and there is no need to disable it.
Also, users can choose friend only instances or invite only instances.
On the other hand, currently for trusted URLs, no matter which instance you enter, they can be accessed instantly and cannot be controlled by the user.
> Don't go into VKET / Furality worlds...
No, it is not safe.
That may be fine for now, but what if, for example, vket distributes assets that have the ability to track users (which is what vcapi is trying to do now, for example)?
It could be sent to vket's URL and track our actions in all possible worlds.
This trusted URL is automatically accessed no matter what world we are in. That suggests that it is not just a matter of not going to vket.
And as I mentioned in my reply to another person, these are not issues that can be solved by me listing them on localhost, but rather by unintentional connections by people I don't know, and to prevent this, I need to ask for explicit consent.
And why shouldn't it be easy?
Consent/refusal for privacy should be easy, and it should be possible for people to refuse even if they don't understand what they are doing. Even if you don't know what you are doing, you don't want your information to be public.
And because they don't know what they are doing, refusing to do so is also an honorable choice on their part.
> And please stop acting like...
At this point, some of it (e.g., scenarios that use it) would be my imagination.
But the fact that it can track usernames and their users is a definite fact.
And it is certainly true that vket is communicating with its own servers in a way that is suspicious of tracking.
And regardless of whether vket is doing so or not, there are concerns that this is happening and we need to know about them and be able to block them.
We have the right to a functional experience. But we also have the right to refuse it.
This is not to deny access to all users, but to allow users who wish to refuse to do so to choose to refuse.
Users who wish to experience the feature must remain able to do so. However, this is not a reason why users who wish to deny it should not be able to do so.
That's right, vrchat is not just for you, not just for me, not just for worldcreators, but for all users.
In order for all users to feel safe utilizing vrchat, those who want to reject third party URLs need to be able to reject them.
> No, this is exactly why
Sorry, I misread your statement.
The string loader was created to load external settings through pastebin etc.
What I was referring to here was passing dynamic information not entered by the user to an external URL for processing.
vrchat is not designed to create these mechanisms.
Tony_Lewis
For GDPR matter, VRChat client itself has Amplitude which not has option to not concent. (anyway not on topic)
For some site not included in whitelist be in whitelist be just outdated docs. (yeap....often happen as you already knows....)
+
Temp Whitelist exception caluse on docs be missing.
Way to fix docs issue, just fork branch and pull request to add missing entry as it is just GitHub.
For way to block it at the moment,
Block traffic on either security software or do it on your firewall.
It is notghing difficult, you can do it easily.
(at least for meanwhile)
Cymbidium
Tony_Lewis:
I did not know about Amplitude.
This could be a problem with this, but I will not discuss it in this ticket because it would complicate the story.
The issue here is not the lack of documentation, nor that it can be easily blocked, but that URLs in Trusted URLs can be accessed and tracked without explicit consent.
This was not a major problem in the past when trusted URLs were limited to video streaming services, but now, when an organization that targets VRChat for business is added to the trusted URLs, the possibility of tracking by a third-party organization without the user's knowledge increases, and the problem becomes more pronounced.
D
Docteh
Where can I find the domain that you are concerned with?
https://creators.vrchat.com/worlds/udon/video-players/www-whitelist/ has a list but it seems the same to me
Cymbidium
Docteh:
In addition to the addresses on this list, the following addresses may obtain user information without our consent.
Other components that can be used for tracking include image-loader and string-loader, which also have undocumented domains.
image-loader
string-loader
These addresses can be found at
D
Docteh
Cymbidium: ah, thanks.
Right now with how the loading mechanisms work there can be an association of a world and ip address and time.
I have seen one world that uses the current systems to automatically record user names of visitors. I believe it's called "world of names", but it's in the description, and is not part of the trusted list. To send your name it would take 50 seconds as it sends each letter individual and an end signal.
One thing that is needed for udon is a response to a remote request for situations where the request is blocked via a lack of being whitelisted.
Furality, fynn and foxcdn are probably for furality, the rest sound very vket related.
Cymbidium
Docteh:
If a URL is not listed on the white list, we believe that access to that URL should not occur even once. However, this is not really relevant to this feature request.
The argument of this feature request is that even if a URL is whitelisted, it must be able to be blocked.
I am generally aware of which URLs belong to which organizations, but this time I have a particular problem with vket.
VKET tracks and records user activity.
In addition, it leases a portion of its subdomain to another third-party organization, giving that organization access to the information of everyone who joins vket's world.
It is also possible for that third party organization to track user activity from worlds not associated with vket, which is very dangerous.
The collection of these users' information requires explicit consent, and the current inability to refuse these requests may be a violation of the GDPR.
D
Docteh
Cymbidium: you should run an SSL man in the middle (SSL stripper?) and inspect the outgoing requests.
I would be interested to see what sort of tracking information the VRChat client is sending with it's requests.
Cymbidium
Docteh:
What response data we receive would need to be captured, but currently I don't think there is any data that can be sent from the vrchat side other than what is included in the URI and a cookie.
Also, the URI where the access was made is shown in the debug log.
It is possible to include a cookie in the response, and one way to track users once they have accessed the vrchat is to track them using a cookie, at least until the vrchat is closed.
Also, the "world of names" that you previously mentioned can be used to send user information.
However, the specifics of these methods are completely irrelevant to this discussion, and the problem is that user information could be shared with these third-party organizations over time, if at all.
D
Docteh
Cymbidium: specifics would matter in a GDPR enforcement action.
Cymbidium
Docteh:
Sorry. I didn't quite understand what you were trying to convey.
I suppose details will be needed when the GDPR is enforced, but right now we are only discussing the fact that such tracking can actually be done, and that there are concerns that it may violate the GDPR, and that some users may want to reject it.
If you are in a position to decide whether the GDPR will be enforced, and are actually considering enforcing it, you may need details of what is actually being done, but I think it should be done in accordance with the legal process.
I am sure that vrchat will then provide you with the information you want, and even the implementation of how udon is implemented in that vket world.
At the very least, the only thing that matters is that an identifying ID or IP address, such as a user name, can be obtained, as you know, and that is not relevant in this case.
In addition, there is no doubt that vrchat is sending some kind of user-specific identification ID, and in addition, the IP address can be recorded.