Privacy Policy

We Are Singular, Lda, incorporated in Portugal (NIPC: PT513858512), operates Daaam. Contact us at [email protected]. Our designated project data-protection contact is Bruno Afonso at [email protected].

This policy describes the Service as it operates today. We will update it before introducing materially different processing, including payment processing or a new monitoring provider.

When Daaam is a controller or processor

We Are Singular is the controller for the account, profile, waitlist, security, and operational data that we decide how to use to operate Daaam.

For files, metadata, comments, and other personal data that a customer places in a Workspace, We Are Singular generally acts as a processor on the Workspace customer’s instructions. The customer or organisation that controls the Workspace is responsible for having a lawful basis to upload, organise, share, and otherwise use that data. If you use Daaam on behalf of an organisation, that organisation may be the controller of your Workspace activity and content.

For a Data Processing Agreement, contact [email protected].

Data we process

Website and waitlist data

Waitlist email: The landing-page waitlist sends the email address you submit directly to Loops so we can manage the waitlist and related communications.
Waitlist rate-limit timestamp: The landing page stores a timestamp in your browser under loops-waitlist-last-submit-at. It does not contain your email address and is used only to prevent repeat submissions within one minute.
Basic request data: Our hosting and edge providers receive network and request information needed to deliver and protect the site, such as IP address, browser information, requested URL, time, and response status.

Account, profile, and authentication data

Email address, user and session identifiers, display name, job title, profile-image URL, and fallback-avatar seed
Password and session operations handled by Supabase Auth; Daaam does not store your plaintext password
Workspace memberships, roles, permissions, invitations, API-key metadata, and registered webhook configuration

Workspace content and metadata

Uploaded images, videos, documents, edits, watermarks, and generated renditions
Filenames, descriptions, alternative text, folders, boards, tags, workflow states, comments, favourites, and share-link configuration
Technical file information such as MIME type, size, dimensions, colour data, and processing state
Embedded EXIF, IPTC, XMP, document, image, and video metadata. Depending on the source file, this may contain names, copyright details, dates, camera or software information, and location data
AI-generated descriptions and object labels, created automatically for eligible newly uploaded raster images; related AI-assisted search data; and text or image queries submitted to search
ZIP job information and the temporary archives generated for requested downloads

You are responsible for reviewing source-file metadata and for having permission to upload personal data relating to other people.

Activity, security, and support data

Workspace audit events, including the acting user, action, affected resource identifiers, event details, IP address, user agent, and time
Request logs, including method, path, status, duration, user identifier, and Workspace identifier
Upload, queue, processing, delivery, and error information needed to operate and troubleshoot the Service
Messages and files you choose to provide when requesting support

Workspace owners and admins can access Workspace audit information, including recorded IP addresses.

Optional product analytics

Authenticated users may explicitly opt in to limited product analytics provided through PostHog EU Cloud. Until a user opts in, Daaam does not load the consent-gated product-analytics client or send product-analytics events for that user. Operational exception capture described below uses a separate PostHog configuration and is not part of this opt-in.

The events use pseudonymous account and Workspace identifiers and limited properties such as the application screen, upload method and file count, search mode and result count, asset category, share creation, or invited-member role. Successful semantic-search events include the exact trimmed search term, its length and word-count buckets, whether it returned results, and its duration. Search terms can contain personal or confidential information, so do not enter information you do not want included in optional analytics. Similar-image searches do not send the selected filename.

Browser analytics events include the full application URL at the time of the event, together with its host and path. The URL can contain the Workspace slug, resource identifiers, query parameters (including submitted search terms), and a fragment. Do not place personal, confidential, or secret information in application URLs or search terms.

Daaam does not intentionally attach profile names, email addresses, filenames, comments, or uploaded content to analytics events. PostHog necessarily receives ordinary network information when the browser sends an event; the product-analytics client is configured to discard IP addresses and not to use session replay, autocapture, heatmaps, automatically displayed surveys, exception autocapture, or Web Vitals. In-app feedback you choose to submit is described separately under In-app feedback.

The preference is stored against the user’s profile together with the applicable notice version and decision time. A user can withdraw consent at any time from Profile. Rejecting a renewed notice or withdrawing consent stops collection and clears Daaam’s token-scoped PostHog local- and session-storage entries, including the persisted browser identity, even when the SDK was not loaded during that page visit. A materially revised analytics notice requires a new opt-in.

Operational exception tracking

Daaam captures unexpected browser, server, and worker application errors through PostHog EU Cloud so we can diagnose failures, protect reliability, and recover service issues. This operational exception capture is separate from optional product analytics, is not controlled by the product-analytics consent preference, and uses a dedicated PostHog configuration that does not load session replay, autocapture, heatmaps, surveys, or PostHog’s built-in exception autocapture.

Exception events may include the error type, message, stack trace, HTTP status when available, and route context needed to locate the failure. Browser exception events include the full application URL at the time of the error, together with its host and pathname. The URL can contain the Workspace slug, resource identifiers, query parameters (including submitted search terms), and a fragment. Server exception events include the request path but not query parameters. Worker exception events include trace and job or version identifiers, processing context, and the active Workspace identifier when the job context is available. They stay anonymous, do not create a PostHog person profile, and disable GeoIP enrichment.

When you are signed in, server-side exception capture uses your pseudonymous account identifier and may attach the active Workspace identifier as a group key. Browser-side exception capture attaches the same pseudonymous identifiers only when your current product-analytics consent is effective; otherwise the browser error client stays anonymous and does not create a PostHog person profile. Logged-out and anonymous server exceptions use a fresh random identifier per event, disable person-profile creation, and disable GeoIP enrichment. PostHog is configured to discard IP addresses for these events.

Daaam does not intentionally attach profile names, email addresses, filenames, comments, or uploaded file content to exception events. Error messages and stack traces may nevertheless contain incidental information if the failing code or URL exposed it.

Legal basis: legitimate interests in operating, securing, and improving the reliability of the Service (GDPR Art. 6(1)(f)).

Retention: PostHog exception event data is retained for 12 months.

Browser storage: The error-tracking client uses memory-only persistence. It does not use cookies or durable local storage for exception capture. See the Cookie Policy.

In-app feedback

Daaam offers an optional feedback form — from the sidebar and from the application error page — so you can tell us what happened or what could be better. Feedback is captured through PostHog EU Cloud using a dedicated client, separate from optional product analytics and from operational exception capture, and is not controlled by the product-analytics consent preference. Submitting the form is itself your consent to send the message and the details described here.

A feedback submission includes your message (free text, which may contain personal or confidential information if you enter it), your profile name when available, the application URL reduced to its origin and path (query parameters and the fragment are removed, so submitted search terms and one-time tokens are not sent), and, when signed in with effective product-analytics consent, your pseudonymous account and Workspace identifiers. Feedback submitted from the error page also includes a correlation identifier that links it to the related exception event. Do not enter information you do not want included when you submit feedback.

Legal basis: consent, given by submitting the form (GDPR Art. 6(1)(a)); and our legitimate interests in diagnosing and resolving issues and improving the Service (Art. 6(1)(f)).

Retention: PostHog feedback event data is retained for 12 months.

Browser storage: The feedback client uses memory-only persistence. It does not use cookies or durable local storage. See the Cookie Policy.

Avatar-request data

Daaam currently uses the hosted DiceBear API to render fallback avatars. The URL seed may be based on a user’s name, email address, or user identifier. When an avatar is loaded, DiceBear and its delivery providers receive that seed in the request URL together with ordinary network data such as the requesting IP address and browser headers.

The landing-page blog uses Gravatar for Daaam author avatars. The browser request contains a one-way SHA-256 hash of the Daaam author’s email address, not the visitor’s email address. Automattic and its delivery providers still receive ordinary request data such as the visitor’s IP address and browser headers.

Billing data

Daaam does not currently offer paid plans, accept payments, use a billing provider, or use a separate infrastructure-monitoring service. We therefore do not currently collect payment-card or billing data for the Service. If billing or monitoring is introduced, we will update this policy and the Terms before that processing begins.

Why we process data

Purpose	Typical GDPR basis
Create accounts; authenticate users; provide Workspaces and features	Performance of a contract (Art. 6(1)(b))
Store, transform, analyse, organise, search, and deliver Workspace content, including generating descriptions and object labels	Customer instructions; contract (Art. 6(1)(b))
Send invitations, security notices, and other service messages	Contract and legitimate interests (Art. 6(1)(b), Art. 6(1)(f))
Operate logs, audit trails, abuse controls, and service recovery	Legitimate interests in security and reliability (Art. 6(1)(f))
Capture unexpected application errors for diagnosis and recovery	Legitimate interests in security and reliability (Art. 6(1)(f))
Receive and act on feedback you submit through the in-app form	Consent by submission (Art. 6(1)(a)); legitimate interests (Art. 6(1)(f))
Manage the waitlist and optional waitlist communications	Consent (Art. 6(1)(a)); you may withdraw it at any time
Collect optional, limited product-analytics events	Consent (Art. 6(1)(a)); you may withdraw it at any time
Respond to rights requests, binding orders, and other legal obligations	Legal obligation (Art. 6(1)(c)); legal claims where applicable

We do not rely on a billing or tax-retention purpose today because the Service does not currently process payments.

How we use Workspace content

Service delivery only: We process content to store, transform, organise, search, watermark, preview, share, and deliver it, and to secure and support those operations.
No AI training: We do not use Workspace content to train our own or another party’s artificial-intelligence or machine-learning models.
Automatic AI descriptions: Eligible newly uploaded raster images are automatically analysed by a hosted AI vision model running on Daaam’s Modal infrastructure. Daaam generates descriptions and object labels, and derives search-indexing data. Descriptions and object labels are stored with the asset version. This is inference on Workspace content to provide the Service; the no-AI-training rule above applies to it.
No sale: We do not sell or monetise Workspace content or its metadata.
Automated processing: Normal media transformations are automated. Authorised personnel may access content only where reasonably necessary for support requested by a customer, security or incident response, service recovery, or a binding legal obligation.
Provider access: The infrastructure providers listed below process content only as needed to provide their part of the Service, subject to their applicable terms.

We disclose data only in these situations:

To other members of the Workspace according to the Workspace’s roles and permissions
To people who receive a share link, including a public or password-protected share
To the infrastructure and communications providers listed below
To a webhook endpoint, WordPress site, API client, or other integration that a Workspace owner or authorised API-key holder configures
To professional advisers, authorities, or another party where required by binding law or reasonably necessary to establish, exercise, or defend legal claims
As part of a corporate transaction, with appropriate confidentiality and notice where required

Customer-configured webhook endpoints, WordPress sites, API clients, and share recipients are not Daaam sub-processors. They are recipients selected by the customer. A webhook may receive asset and folder identifiers, version identifiers, name, alternative text, description, and tags. Customers are responsible for the destination, its security, and its own privacy terms.

Current service providers

Provider	Current purpose	Processing notes
Supabase	PostgreSQL database, authentication, and Realtime	Primary project region is EU West (Ireland); provider support and sub-processing may be elsewhere
Backblaze B2	Original files, generated media, and temporary download storage	Production object-storage endpoint is in Backblaze’s EU Central region
Cloudflare	Application and edge delivery, CDN/cache, queues, DNS, rate limiting, email, and AI-assisted search (Workers AI for text processing; Vectorize for search indexes)	Operates a global network and may process request, cache, queue, email, and search data internationally
Modal	Media transformation, image delivery, watermarking, ZIP processing, and AI processing for automatic descriptions and image-based search	Receives files, generated image renditions, file metadata, storage credentials, and job identifiers needed for processing
Loops (Astrodon Corp.)	Landing-page waitlist collection and waitlist communications	Receives the email address submitted to the waitlist
DiceBear (Florian Körner)	Hosted fallback-avatar rendering	Receives the avatar seed in the URL and ordinary request metadata
Automattic (Gravatar)	Landing-blog author avatars	Receives a hash of Daaam’s author email and ordinary visitor request metadata
PostHog EU Cloud	Optional product analytics; always-on operational exception capture; in-app feedback	Product analytics (consent-gated): pseudonymous identifiers, full application URLs, submitted semantic-search terms, and approved event properties. Exception capture (legitimate interest): error type, message, stack, status, route or full application URL, and pseudonymous identifiers as described above. Feedback (submission as consent): your message free text, profile name when available, application origin and path, and pseudonymous identifiers as described above

See GDPR & Data Processing for first-party provider documentation and international-processing details.

Storage delivery and security boundaries

We use HTTPS for application, API, upload, processing, and delivery traffic. We apply role-based access controls, Workspace-scoped database access, signed upload operations, restricted infrastructure credentials, and credential redaction in application logs.

The current production object-storage bucket supports public reads so media can be delivered through Daaam’s proxy and CDN. Object keys are designed to be difficult to guess, but a person who obtains a valid direct object URL may be able to retrieve that object without the Daaam Workspace permission check. A copied direct object URL should therefore be treated as a bearer link, not as an access-control boundary. Share links can also be forwarded by their recipients. Use share passwords and expiry controls where appropriate, and do not upload material whose risk profile requires end-to-end encryption or a private object-store access guarantee that Daaam does not currently provide.

No online service can guarantee absolute security. Contact [email protected] if you believe data or credentials have been exposed.

Retention

Account and profile data: Retained while the account is active and then handled through the manual deletion procedure described on our GDPR page
Workspace data and content: Retained while the Workspace exists. Moving an asset to Trash hides it but does not start an automatic 30-day deletion; it remains until an authorised user restores or permanently deletes it
Abandoned uploads and temporary jobs: Incomplete upload reservations and generated download jobs are subject to operational cleanup. A completed ZIP download is offered for 24 hours; related temporary records and files may remain briefly while cleanup and provider lifecycle rules run
Workspace audit data: Retained with the Workspace. If an account is removed from a shared Workspace, the event may remain for accountability, but we will remove or anonymise personal fields where required by an approved deletion request
Authentication data: Access and refresh sessions have configured lifetimes of up to 7 and 30 days respectively, and may end earlier on sign-out, revocation, or account deletion
Waitlist data: Retained until you unsubscribe, request deletion, or the waitlist purpose ends, subject to limited provider, legal, and suppression records
Operational logs: Retained for the period reasonably needed for security, reliability, troubleshooting, and legal claims. We do not currently publish a single fixed retention period because the period depends on the log and hosting system
Product analytics and operational exceptions: PostHog product-analytics and exception event data are retained for 12 months. The user’s product-analytics consent decision and notice version remain with the account profile so Daaam can enforce the current preference
Backups: Deletion is applied to live systems first. Residual provider backup copies, if present, remain isolated from normal use until the applicable provider or operational backup cycle expires. If a backup is restored, completed deletion requests must be reapplied
Billing and tax records: None are created by the current Service. If payment processing is introduced, the applicable records and retention periods will be disclosed before billing begins

International processing

The primary Supabase database is configured in Ireland and the production Backblaze object-storage endpoint is in the EU Central region. That does not mean every processing operation stays in the EEA. Cloudflare operates a global edge network, and Modal, Loops, provider support systems, provider sub-processors, avatar delivery infrastructure, and customer-selected integrations may process data in other jurisdictions. Product analytics uses PostHog’s EU Cloud project; PostHog support systems and sub-processors may still operate from other jurisdictions under its applicable transfer safeguards.

Where GDPR rules apply to an international transfer for which We Are Singular is responsible, we use an applicable transfer mechanism and supplementary measures where required. Provider locations and sub-processors can change; contact our data-protection contact for the current contractual details. A customer that selects an external webhook, WordPress/API destination, or share recipient is responsible for the transfer it instructs us to make.

Your rights

Subject to the conditions and exceptions in applicable law, you may request access, rectification, erasure, restriction, portability, or objection, and may withdraw consent. These rights apply to all our users where doing so is practical, even when the GDPR does not directly apply.

Email [email protected] or contact Bruno Afonso. We normally respond within one month after receiving and, where necessary, verifying a request. See our GDPR page for the complete request and deletion procedure.

Law-enforcement and illegal-content requests

We may preserve or disclose data where required by binding Portuguese or EU law, a valid court order, or another lawful request from a competent authority. We review requests and limit disclosure to data we hold that is legally required.

If we become aware of apparently illegal or seriously harmful content, we may restrict access, preserve relevant evidence, and report it where required or permitted by applicable law. This statement does not claim that Daaam currently performs general automated content scanning.

Supervisory authority

You may lodge a complaint with the CNPD (Comissão Nacional de Proteção de Dados) or, where applicable, the data protection authority in your EU/EEA country of residence or work.

Cookies and browser storage

We use strictly necessary authentication and protected-share cookies, a waitlist rate-limit timestamp, memory-only PostHog storage for operational exception capture, and—only after product-analytics consent—PostHog local storage for optional analytics.

PostHog is configured not to use cookie persistence for either path. We do not use advertising or cross-site behavioural-tracking cookies. See our Cookie Policy.

Children

Daaam is not directed at individuals under 16, and accounts may not be created by anyone under 16. Contact us if you believe a child has provided personal data contrary to this policy.

Changes to this policy

We will update the date at the top when this policy changes. Where a change materially affects how we process personal data, we will provide any advance notice or renewed choice required by applicable law before the change takes effect.