The Two-Person Data Problem
Most privacy frameworks are designed around a single data subject. You have data about yourself — your name, your email, your activity — and the question is how that data is collected, stored, used, and deleted. The framework is clean because the subject is singular. You can consent on your own behalf. You can request deletion of your own data. The responsibility chain is relatively simple.
Apps that connect two people introduce a complication that most privacy discussions don't address: some of the data doesn't belong to either person alone. When two people create a shared listening session, the session record is about both of them. When one person invites another, the invitation contains data about the invitee that was entered by the inviter. When session history is stored, it's a history of what two people did together, not what one person did.
This creates a genuinely interesting set of questions. If one person wants to delete their account, what happens to the shared data? If one person's data needs to be retained for legitimate reasons (compliance, ongoing disputes), but the other wants erasure, how do you resolve the conflict? If Person A knows Person B's email because they entered it into the app, is that email now Person A's data, Person B's data, or data belonging to the app?
These questions don't have universally correct answers. But they have to be answered, explicitly, before you write the data model. If you answer them afterward, you'll have built the wrong thing.
Minimum Necessary Data in Multi-User Contexts
The principle of minimum necessary data collection — collect only what you need for the stated purpose — is standard privacy practice and relatively easy to apply for single-user apps. For connected apps, it requires an additional question: minimum necessary for whom?
To connect two people in a listening session, you need some way to identify both of them and some way to establish a trusted relationship between their accounts. The minimum for this is: an identifier for each account, a way for one user to specify the other, and a permission mechanism for the other to accept or decline the connection. What you don't need: their real names, their phone numbers, their location, their listening history outside of the session, or any other data that isn't load-bearing for the connection itself.
The temptation in connected apps is to collect more because more data makes the experience richer. Knowing your partner's listening history outside of shared sessions could improve recommendations. Knowing your location could enable location-based features. Knowing your contacts could make finding your partner easier. Each addition has a plausible rationale. Each addition also enlarges the privacy surface area — more data means more exposure, more deletion complexity, more potential for misuse.
The discipline is to be concrete about what's actually necessary and to hold that line against the gravitational pull of "this would be nice to have." Nice-to-have features that require additional data collection are not free. They cost user trust, and they create obligations around data handling that outlast the feature.
The DPDPA 2023 Context
India's Digital Personal Data Protection Act, which received presidential assent in August 2023, establishes a framework for personal data protection that applies to any entity processing the personal data of Indian citizens. For Indian app developers, this isn't an abstract compliance exercise — it describes obligations that apply to every app we ship.
The DPDPA establishes several principles that are particularly relevant for connected apps: the right to consent, which must be specific and informed; the right to access, allowing users to know what data is held about them; the right to correction; and the right to erasure. For connected apps, the erasure right is the most complex, for the reasons discussed above — erasing one user's data from a shared session record without erasing the other user's session history is a genuinely hard technical problem.
The Act also establishes accountability obligations for data fiduciaries — which is what app developers are — including the requirement to implement appropriate security measures, maintain data only as long as necessary, and notify affected users in the event of a data breach. None of these are unreasonable. All of them require deliberate engineering decisions, not afterthought compliance checkbox-ticking.
I'm not going to pretend that building for DPDPA compliance is simple or that we have all the answers. But approaching privacy as a design constraint rather than a compliance obligation changes what you build. Constraints imposed early, before the data model is set, produce fundamentally better outcomes than retrofitted compliance layers added after the fact.
Why Deletion Is Harder When Two People Are Involved
Account deletion for a connected app has to answer a question that single-user apps don't face: what happens to the shared data when one side of the connection is deleted?
The naive answer is: delete everything associated with the deleted account. This is clean and defensible. It also potentially deletes data that belongs — in some meaningful sense — to the other user. A session history that represents both people's shared activity isn't solely the deleting user's data to remove unilaterally.
A more nuanced answer: on deletion, anonymise rather than delete. Replace the deleted user's identity within shared records with a placeholder, preserving the shared activity records for the remaining user while removing the deleted user's identifiable information. This approach threads the needle between erasure rights and data belonging to third parties.
The right answer depends on your data model and your assessment of what each piece of data is actually for. What's clear is that this is a question you must answer explicitly, and that "we'll figure it out when someone asks to delete" is not a policy. It's a liability.
Consent in Multi-User Contexts
Consent is typically presented as a straightforward mechanism: the user reads a thing, clicks agree, and consent is established. In multi-user contexts, consent is more complicated, because some actions that affect one user are initiated by another.
When someone invites a partner to a shared session, the partner's data — their account identity, their listening activity within the session — is now part of something the inviter created. The partner consented to joining the session, but did they consent to all of the data implications of that session? If the session history is stored, and the inviter's account is later shared with or accessed by a third party, the partner's session data goes along for the ride.
These scenarios require consent flows that are explicit about what shared data means and what each party's rights are within the shared context. This is more friction than most apps want in an onboarding flow. It's less friction than the alternative of having users discover their data implications after the fact.
Building for the Harder Case
Privacy thinking that anticipates edge cases produces better software than privacy thinking that only handles the normal flow. The user who wants to delete their account after a relationship ends, where the shared session history is now unwanted. The user who never consented to their email being stored as an invitee. The user whose partner account was compromised and who wants to disconnect without losing their own history.
These aren't hypothetical edge cases invented for a privacy checklist. They're real situations that real users of connected apps encounter. An app that has thought through these situations in advance handles them gracefully. One that hasn't handles them with a support ticket, a delayed response, and a workaround that wasn't designed for the situation.
At The VoBot Developers, across Twunein and our other apps, the commitment is to treat privacy as a design input rather than a legal afterthought. That means making decisions about data collection, storage, and deletion before the data model is finalised. It means writing deletion flows that actually work. It means being honest about what data the app holds and why. The questions this raises are inconvenient. The alternative is building systems that fail users when they need them most.