[DAO:a3f6851] Anonymizing User's Position Information

by 0xb8782cf628357ce2751a4ea3007934048fbaa672 (deadpool#a672)

Linked Pre-Proposal

Prevent harassment and surveillance of all users via overly-exposing endpoint


To safeguard users’ privacy, stop exposing their wallets with their current positions; instead, utilize anonymized session IDs to prevent public identification of user locations within the platform.


There were extensive and heated debates regarding the disclosure of users’ wallets with their current positions. Ultimately, the decision was made to maintain open data, leading to the emergence of new wallet analytics apps in Decentraland. However, the fact that anyone could get a detailed analytic dashboard with users names and activity for any wallet raised concerns about data privacy breaches, causing discomfort and preoccupation about privacy safeguards.


A misalignment exists between Decentraland’s data privacy policy, which has raised user concerns, and the potential conflict regarding the disclosure of user behavior.


Catalyst’s communication server exposes API endpoints that broadcast user wallets and real-time locations, enabling anyone to:

  • Track user movement: This data can be used to create user behavior analytics, potentially revealing specific user habits and routines.
  • Facilitate harassment: Malicious actors could exploit this information to harass other users on the platform.
  • Lack of opt-out: Currently, there’s no way for a platform user to prevent their wallet address and location from being displayed in the API results.

Proposed Solution: Balancing Transparency and Privacy with Anonymouse Session IDs and Metrics

While recognizing the value of public platform metrics and analytics, an alternative approach can address privacy concerns. Instead of removing the endpoint entirely, wallets could be replaced by anonymous session IDs. Here’s how it would work:

  1. Session ID Generation: Whenever a user connects to Decentraland, a unique and anonymous session ID is generated.
  2. Replacing Wallets: This session ID would replace the user’s wallet address in all API responses.
  3. Unlinkable Sessions-Wallet: Since new session IDs are generated for each connection, linking them back to specific user wallets would not be possible.

This API change will come along a new endpoint to help scenes validate users’ positions, the operation will be as follows:

  • Input: This API would accept a user’s sessionId or wallet and a specific range of parcels within the scene.
  • Output: The API would respond with a simple “true” or “false”:

True: indicates the user is present within one of the specified parcels.
False: indicates the user is not present in any of the queried parcels.

This approach offers a balanced solution. Public platform metrics can still be obtained for analytics purposes and scenes will still be able to validate user’s positions while privacy is protected by anonymizing user data through session IDs.


The proposed solution balances transparency and privacy by replacing wallets with anonymous session IDs. This approach maintains the value of public platform metrics and analytics while safeguarding user privacy.

Vote on this proposal on the Decentraland DAO

View this proposal on Snapshot

1 Like

Would there be a new ID generated upon each visit? Or would the user retain the same ID throughout their history of visits the parcel? I ask because this could raise a security issue for game makers who need to ban certain players for exploitation/breach of game terms.

1 Like

As far as I understand, it would be anonymizing the user address only on the catalyst endpoint (https://peer.kyllian.me/comms/peers for example), not the one in world.
It might cause some changes in the POAP dispenser for example as instead of just checking the user address, the user will have to send their new session ID to the server so it can verify the user position against a catalyst.


What @HPrivakos mentions is correct.
The session ids won’t be preserved in history and there will be one new per session.

1 Like

So will game makers have access to the wallet on the client side to prevent abuse/exploitation from certain wallets? @paralax

1 Like

You still have access to user profiles as it is public, and if there’s a need to validate a game interaction between a specific user and their location, a new endpoint will be provided for that purpose and nothing else will change.


Can you clarify please how the proposal manages the risk of data access centralization ?

sorry, I didn’t see your question before and I missed it, didn’t mean to avoid your question.
I’m uncertain if I grasp the concern entirely. The services won’t disclose the data, and the published service version won’t inherently expose any of these metrics. If you host a catalyst, it’s entirely open-source, and there’s always a way for the potential for manipulation. However, as a node owner, you wouldn’t be using the allowed version of the catalyst node. If such manipulation is detected, a DAO poll could be conducted to take down the node.

The Foundation proposing this while collecting metrics on everyone is really a joke :slight_smile:

Enforcing a single “Foundation version” is very dangerous =) (also, if you modify your catalyst, you can modify it in such a way it reports the correct docker hash while not using that docker image)

We must balance open data with protecting user information.

“open data for us for not for you”

It will make keeping track of unique users visiting parcels harder and make accountability for grantees nearly impossible.


Thank you for this HP, changing my vote to NO.

I didn’t mean to say that there will be an only allowed version built by the foundation.
The point here is that as nose owner, with an open protocol and open source code there is no way to guarantee that the owner cannot access the data and collect it.
What we are discussing here is about publicly exposing user wallets and positions which enable the public user behavior analytics.

Anonymizing User’s Position Information

This proposal is now in status: REJECTED.

Voting Results:

  • Yes 40% 3,539,453 VP (68 votes)
  • No 60% 5,172,435 VP (13 votes)
  • Abstain 0% 0 VP (0 votes)