Legitimate Interest Assessment
Last updated: April 2026
Under GDPR Art. 6(1)(f), organisations that rely on legitimate interest as a legal basis for processing personal data must conduct a three-part balancing test: identify the legitimate interest, demonstrate that processing is necessary to achieve it, and verify that the data subjects' interests and rights do not override. This document covers all processing activities where Sifa relies on legitimate interest.
This assessment accompanies our Privacy Policy.
Unclaimed profile display
What is processed
When someone visits a Sifa profile page for an Atmosphere user who has not claimed their profile, Sifa fetches basic identity data from the public Atmosphere network: handle, display name, and avatar. This data is cached in memory for up to 5 minutes. It is never written to our database. No activity stats, professional history, or other enriched data is shown. The profile page displays a notice that the profile is unclaimed, with links to the privacy policy and the removal request form.
Legitimate interest
Sifa's purpose is to provide a professional identity layer for the Atmosphere ecosystem. Displaying basic identity pages makes Sifa discoverable as a directory and benefits profile visitors (recruiters, collaborators, peers) who want to look up any Atmosphere user's professional presence. Atmosphere users also benefit from discoverability: an unclaimed profile page serves as a prompt to claim and enrich their professional presence.
Necessity
To display a profile page, Sifa must fetch and render identity data. There is no way to show a useful profile page without the handle, display name, and avatar. Showing only opted-in users would eliminate directory value entirely. Only three fields are processed (handle, display name, avatar), which is the minimum set needed for a recognizable profile page.
Balancing test
| Factor | Assessment |
|---|---|
| Reasonable expectations | The Atmosphere is a public, federated system. Users who create an Atmosphere account are informed that their identity data is publicly accessible. Apps reading public data is the protocol's intended architecture. |
| Nature of data | Low sensitivity. Handle, display name, and avatar are public identifiers the user chose to publish. No private, sensitive, or special category data is processed. |
| Impact on data subjects | Minimal. The data is already publicly accessible via the Atmosphere, Bluesky, and any other Atmosphere app. Sifa adds no new data or context beyond what is already public. The profile page explicitly states it is unclaimed. |
| Relationship | No direct relationship. This is the primary factor requiring careful consideration. Mitigated by: (a) data is already public by the user's own choice, (b) processing is minimal (read-only, no storage), and (c) a self-service removal mechanism exists. |
| Safeguards | Removal request form at sifa.id/privacy/removal (no Sifa account required). Suppression list prevents re-indexing. No database storage. Short cache TTL (5 minutes). Privacy policy publicly available. |
Conclusion
The data subjects' interests and rights do not override the legitimate interest. The processing is minimal (three public fields, no storage, short cache), the data is already publicly available by the user's own choice on a protocol designed for public access, and a self-service removal mechanism ensures any user who objects can stop processing immediately.
Activity content caching
What is processed
When a visitor views a claimed Sifa profile, Sifa reads recent activity content (posts, code commits, articles, etc.) live from the profile owner's data server or the relevant app. This content is cached in memory for 5 to 15 minutes depending on content type. It is never written to our database. Aggregate activity statistics (which are stored) are covered by our separate Data Protection Impact Assessment.
Legitimate interest
Displaying activity content is essential to Sifa's value proposition as a portable professional identity platform. Users who claim their Sifa profile actively seek to showcase their professional activity. Profile visitors gain access to authentic, externally-sourced professional activity rather than unverifiable self-reported claims.
Necessity
Caching is necessary for performance. Without caching, every profile page view would require multiple live API calls to the user's data server, creating unacceptable latency and placing disproportionate load on data server infrastructure. The current 5 to 15 minute TTL balances performance with freshness.
Balancing test
| Factor | Assessment |
|---|---|
| Reasonable expectations | Direct relationship. User claimed their profile knowing activity would be displayed. Fully expected. |
| Nature of data | Public data the user voluntarily published on Atmosphere apps. May include casual content displayed in a professional context. |
| Impact on data subjects | Low. Content is already public. The primary risk is context collapse (casual posts in professional setting), mitigated by per-app visibility controls. |
| Safeguards | Per-app opt-out in settings. Short cache TTL (5 to 15 minutes). No database storage. Content deleted at source disappears from Sifa within minutes. Full erasure mechanism available. |
Conclusion
Legitimate interest is appropriate. Direct relationship, aligned expectations, minimal processing (volatile cache only), comprehensive opt-out controls.
Import metadata
What is processed
When a user imports their LinkedIn profile data through Sifa, we log when the import happened and how many items were imported per category (for example, 12 positions, 8 skills). We do not store the imported content itself. This metadata is stored in our database and retained until account deletion.
Legitimate interest
Import metadata enables Sifa to understand product usage patterns, identify import issues, and improve the import experience. It also provides an audit trail if a user reports problems with their import.
Necessity
Without import metadata, Sifa cannot diagnose import failures, understand which LinkedIn categories users most commonly import, or provide support when users report issues. The metadata is the minimum set needed: timestamps and counts, not content.
Balancing test
| Factor | Assessment |
|---|---|
| Reasonable expectations | Direct relationship. Users actively trigger the import. Logging metadata about the operation they initiated is standard practice. |
| Nature of data | Very low sensitivity. Timestamps and integer counts. No content, no identifiers beyond the user's own account. |
| Impact on data subjects | Negligible. The metadata reveals only that an import occurred and its rough scope. |
| Safeguards | Deleted on account deletion. Not shared with third parties. Not used for profiling. |
Conclusion
Legitimate interest is clearly appropriate. Minimal data, direct relationship, standard operational practice.
Analytics
What is processed
Sifa uses Umami for website analytics. Umami is open-source, cookieless, and self-hosted on our own infrastructure in the Netherlands. It collects anonymous, aggregate data: page views, referrer URLs, browser type, operating system, screen size, and approximate country. No data is sent to third parties. Umami cannot link analytics data back to individual users or Sifa accounts.
Legitimate interest
Understanding how visitors use the site is necessary for product development, identifying technical issues, and making informed decisions about features and content. This is a standard and expected practice for any website operator.
Necessity
Without analytics, Sifa cannot understand which features are used, where users encounter friction, or how the site is discovered. Server-log-only analytics would be less accurate (bots, caching distortion). Third-party analytics (Google Analytics, etc.) would be more intrusive. Umami self-hosted is the most privacy-respecting option available.
Balancing test
| Factor | Assessment |
|---|---|
| Reasonable expectations | Website analytics is universally expected. Visitors to any website reasonably anticipate that aggregate usage data is collected. |
| Nature of data | Anonymous and aggregate. No personal identifiers, no cookies, no cross-session tracking. Cannot be linked to individuals. |
| Impact on data subjects | Negligible. Data is anonymous by design. No individual-level processing occurs. |
| Safeguards | Self-hosted (no third-party data sharing). Cookieless (no tracking). Open-source (verifiable). No individual profiles built. EU-hosted. |
Conclusion
Legitimate interest is clearly appropriate. The processing is anonymous by design, uses the least intrusive analytics tool available, and aligns with universal expectations.
Server logs
What is processed
Sifa's servers log request metadata for each HTTP request: timestamp, HTTP method, request path, response status code, and IP address. Logs are stored on the server filesystem in Germany and rotated after a maximum of 30 days. They are not stored in the application database and are not used for analytics or profiling.
Legitimate interest
Server logs are essential for two purposes: debugging technical issues (identifying errors, diagnosing performance problems, reproducing bugs) and protecting the service against abuse, spam, and denial-of-service attacks. IP addresses are necessary for both purposes.
Necessity
Without server logs, Sifa cannot diagnose errors, identify abuse patterns, or respond to security incidents. This is a fundamental operational requirement for any internet service. Logging without IP addresses would prevent abuse identification. Shorter retention (under 30 days) would be insufficient for investigating intermittent issues.
Balancing test
| Factor | Assessment |
|---|---|
| Reasonable expectations | Server logging is universally expected and understood. Every internet service logs request metadata. |
| Nature of data | IP addresses are personal data under GDPR, but here they function as technical identifiers, not as tools for individual profiling. Request paths may contain handles but no sensitive content. |
| Impact on data subjects | Low. Logs are used only for debugging and security. Not used for analytics, profiling, or any other purpose. 30-day rotation limits exposure. |
| Safeguards | 30-day maximum retention with automatic rotation. Stored on EU servers (Hetzner, Germany). Not in application database. Access limited to system administrator. Not shared with third parties. |
Conclusion
Legitimate interest is clearly appropriate. Server logging is a fundamental operational necessity, universally expected, with proportionate retention and strong access controls.
Suppression list
What is processed
When an Atmosphere user requests removal of their unclaimed profile from Sifa (via sifa.id/privacy/removal), Sifa stores their DID (a permanent unique identifier assigned by the Atmosphere) and the date of the request on a suppression list. This list is stored in the application database and retained indefinitely.
Legitimate interest
The suppression list is the mechanism by which Sifa honours removal requests permanently. Without it, a removed profile could reappear after a cache flush, server restart, or any event that causes Sifa to re-encounter the identifier on the Atmosphere network. The suppression list directly serves the data subject's expressed wish not to appear on Sifa.
Necessity
The Atmosphere is a live, federated network. Sifa encounters identifiers through the event stream and direct lookups. Without a persistent record of which identifiers have requested removal, Sifa cannot distinguish between users it has never seen and users it previously removed. The DID is the minimum identifier needed (handles can change; DIDs are permanent). Time-limited suppression would eventually violate the user's removal request.
Balancing test
| Factor | Assessment |
|---|---|
| Reasonable expectations | The user explicitly requested removal. Storing the minimum data needed to honour that request permanently is not only expected but desired by the data subject. |
| Nature of data | A DID (public identifier) and a date. No other personal data. |
| Impact on data subjects | Positive. The processing exists solely to protect the data subject's interests. |
| Safeguards | Minimum data stored (DID and date only). No other processing of suppressed identifiers. Data subject can request deletion of the suppression record (understanding that their profile may then reappear). |
Conclusion
Legitimate interest is clearly appropriate. The processing serves the data subject's own expressed interest and uses the minimum data necessary to do so.
Review schedule
This assessment was completed in April 2026 and is reviewed annually, or when processing changes materially. The most recent review date is shown at the top of this page.