Description:
Introduce a network-level feature that allows users to issue a “forget me” request. This feature would trigger a profile update that replaces the user’s existing data with empty values, signalling their intent to withdraw personal information from the network.
While it may not guarantee the deletion of all data historically stored across the network (due to decentralised persistence), the latest version of the user’s profile will effectively become blank.
Currently, if a user deletes their account, public user profile information persists for 30 days until the peer-to-peer network clears the data from its cache. The “forget me” feature would aim to expedite or facilitate this process, reducing the visibility of user data during this interim period.
Use case: As a user, I want to issue a “forget me” request so that I can exercise control over the visibility and retention of my personal information on the network.
Target user:
Users who value privacy and want to manage their personal data visibility across a decentralised network.
Why this is important:
Empowers users with more privacy control and aligns with privacy-centric principles.
Addresses growing expectations for data minimisation in decentralised systems.
Demonstrates commitment to ethical data practices, enhancing trust and user satisfaction.
Reduces the duration during which a user’s data remains publicly visible after account deletion, addressing privacy concerns tied to the current 30-day cache-clearing window.
Any other comments:
Acknowledging the complexity of data persistence in decentralised networks, the implementation should include clear communication to users about the scope and limitations of the “forget me” feature.
Additional mechanisms to encourage network participants to honour the “forget me” intent could further enhance the efficacy of this feature.
Explore ways to optimise the 30-day cache-clearing process, potentially shortening it as part of the feature’s rollout.
It can work well for the different peers since we control the protocol.
Obviously, as you pointed out, we are decentralized and open-source so we cannot guarantee that every peer will have that request implemented or respected, but having a warning is good enough.
My only concern is with the history nodes.
I don’t think we can easily have a way to “wipe” data from them, since they are fully agnostic of the data put on them and if we introduce a mechanism to erase data, we’d have to be very careful to ward any attacks it could entail.
One option would be to only have it on the client protocol side. We could save in a database table the user keys that asked to be forgotten and ignore any data we would fetch about them.
There is the issue that if the forget-me message is lost, then some people would still fetch data from them by accident, but if we make the forget-me also leave all communities and groups, that chance is lowered.
I agree with you on all of that, @JoRain. I think whatever we do, the first step will likely involve client-side changes. You make an excellent point that altering node behaviour, particularly history nodes, is risky. Reaching into history nodes and triggering deletion makes me feel uneasy as well, it introduces complexities and potential attack vectors that we’d should avoid entirely.
You’ve also made me think about the protocol layers here. Store nodes function as transport (kind of), and introducing “forget-me” as a concept which is rooted in the chat protocol layer would blurs that distinction. It’s important to preserve these boundaries.
The point about the “forget-me” message getting lost is a good one, too. Perhaps we can think about some mechanisms for redundancy or safeguards in the process:
We could explore mechanisms like periodic retransmissions of the “forget-me” request.
Although this may not be possible, a user triggering a “forget-me” message may not continue to use the application.
A sequence of “forget-me” messages disguised as a “deleting …” loader?
Requiring ACK from communities and groups to ensure it propagates fully.
Making sure the feature is robust will definitely require some thoughtful design.