Now the cookie jar is broken, we need a new one.
nHaruka
## In Short ##
I suggest restructuring a cookie mechanism with some assurance of user privacy.
## Body ##
From the latest update of VRChat,
set-cookie
header cannot set cookies, the client just ignores it. I assume this change is to prevent tracking like 3rd party cookies. To inhibit such things should be wanted from everyone.However, we must recall such things are a trade-off for creativity in VRChat. This means sometimes cookies are helpful to the users and creators and we must not ruin them. I suggest the following methods somewhat make sense while keeping suppress tracking that violates the user’s intent.
### 1. Isolated cookie jar par worlds or world authors ###
To isolate cookie jar per some unit (like worlds or world authors) allows for some degree of anti-tracking. Cases in which we’d like to share the cookies between worlds of the same author happen when the developer wants to share some progress between worlds, for example. This is probably outside of the world persistency feature, and there are other applications besides this one.
### 2. User-approval cookies (or, user-approval fetching) ###
The client should allow cookies that the user has permitted (Of course we should also prohibit “force-allowed worlds” in the guidelines, which require to allow cookies and if you don’t, they’ll disable whole features in the worlds).
Perhaps, this approval mechanism should be more flexible than “allow untrusted URLs”, like on-the-time or origin-based approval from the setting pane like access permission on smartphones. Or, we may merge these features, currently, we only have two ways; allow trusted URLs or allow all. These user-approval systems can provide another way to control privacy or security (this is another story…).
Of course, it is possible to construct a login system on VRChat that leverages these mechanisms, but in such cases, the user needs to explicitly login on each world (if we implemented 1.), so that should be the tracking that the user already recognized (I’m just guessing how the set-cookie was deleted, I may be missing the point though…).
Log In
Prismic247
This would really enhance what's possible in VRChat worlds in subtle but profound ways. Cookies were already exclusive to individual VRChat sessions before their removal, but if allowed and made exclusive to a world or even an instance or some other criteria as the poster suggested, would still enable some excellent stuff difficult or impossible to do practically otherwise.
One example is a rotating set of images. Suppose you want to cycle through a series of banners in your world using remote image loading, but want the list to be dynamic and not require updating the world to add new urls. Having a single url that could increment a cookie and return a different image each subsequent request (or the same for JSON data objects in string requests) would be useful and practical.
Another is differentiation between users from the same location. In VRCanvas for example, I ratelimit placements based on ip alone, which means people from the same household are treated as the same person and often have issues in the world. Having a cookie set per person/session would allow for multiple people to be recognized as being from different sessions without providing any additional identifiable information than what's already possible.
Tupper - VRChat Head of Community
open