Harmonizing the Digital Self: A Data-Centric Approach to Multi-Site Identity Consistency
Maintaining a Consistent Representation of Self across Multiple Social Networking Sites -- A Data-centric Perspective
This paper proposes a data-centric framework for Social Identity Management (SIdM) that enables users to maintain a consistent representation of self across multiple Social Networking Sites (SNS). It introduces a structured transformation approach to map personal attributes and their visibility settings between platforms like Facebook, LinkedIn, and Twitter.
TL;DR
In an era where we juggle professional personas on LinkedIn and social ones on Facebook, maintaining a consistent yet "faceted" identity is a manual nightmare. This paper moves beyond conceptual privacy talk to provide a data-centric framework for synchronizing personal attributes across Social Networking Sites (SNS). By analyzing the underlying metadata of attributes—such as data types, ownership, and API accessibility—the authors propose a structured method to migrate profiles without losing semantic meaning or compromising privacy.
The "Context Collapse" Problem
Most users operate in multiple "social spheres" (work, family, hobbies). In the physical world, we naturally change our behavior based on the audience. Online, this is called Social Identity Management (SIdM).
The technical pain point is twofold:
- Platform Silos: Each SNS implements attributes differently. What LinkedIn calls "Position," Facebook calls "Work."
- Access Control Heterogeneity: Facebook allows "Friends of Friends" visibility, while Twitter is often "All or Nothing." Manually syncing these leads to "oversharing" (revealing too much on a restrictive site) or "undersharing" (failing to connect).
Methodology: The Transformation Pipeline
The authors propose a 4-step workflow to move an attribute from site to on .
1. Semantic Matching
Before moving data, the system must ensure the attributes mean the same thing. This involves comparing names (e.g., "Birthdate" vs "DOB") or using RDF/semantic reasoning for complex fields.
2. Structural & Content Analysis
This step checks if the "container" matches the "content."
- Data Types: Can a "Location" object on Facebook be simplified into a "String" on Twitter?
- References: How do we handle "Tags" or "Links" to other users if those users don't exist on the target platform?
3. Visibility Alignment
This is the most critical phase for privacy. The authors use Venn diagrams to visualize the overlap between contact lists across sites.
Fig 1: Identifying the intersection of contacts () to determine if an attribute should be visible or hidden on the new platform.
4. API Execution
Finally, the system checks if it actually has the rights to write data. Many APIs (like LinkedIn's at the time of writing) are "Read-Only" for certain sensitive fields, forcing a manual fallback.
Real-World Validation: LinkedIn vs. Facebook
The researchers mapped professional "Experience" from LinkedIn to Facebook's "Work" section.
Table 1: Comparative analysis showing that while LinkedIn's "Position" maps well to Facebook's "Work," Facebook offers more granular privacy (subsets of contacts) that LinkedIn lacks.
Key finding: Status Updates (Facebook) and Tweets (Twitter) are semantically similar but structurally divergent. Twitter’s 140-character limit (at the time) and its lack of threaded "appendable" comments (unlike Facebook’s nested comments) create "structural loss" during migration.
Critical Insight & Future Outlook
The core discovery here is that Consistency Identity. A user might want different representations, but they want those representations to be managed from a single source of truth.
Limitations:
- The API Wall: As SNS providers become more protective of their data "moats," the ability to automate this via API (Step 4) is decreasing.
- Incidental Data: Comments and tags made by other people remain a major hurdle for identity consistency since the user doesn't "own" that data.
Takeaway: The future of SIdM likely lies in Decentralized Identifiers (DIDs) where the user stores a "Master Profile" locally and "projections" are pushed to various SNS, rather than relying on the platforms to talk to each other.
