Privacy

Dhaga Cloud is operated by Ekasmi TechLabs Pvt. Ltd., I-706, R10, Universe Avenue, Life Republic, Kolte Patil, Hinjewadi, Pune 411067, Maharashtra, India. "We" and "us" on this page mean that company. Questions about anything below, or about the data we hold on you, go to contact@ekasmi.com.

Almost certainly Dhaga Cloud, which is how Dhaga is delivered unless you have specifically arranged otherwise with us: your data sits in our managed Postgres database, encrypted at rest and in transit. The tables that hold your contacts, notes, tasks, calendar and messages are protected by row-level security, so a signed-in user's queries cannot return another user's rows. The exceptions are what you choose to share with a colleague and the records that belong to an organization you are in, which can be read as described under “If you use Dhaga inside an organization” below. Account, sign-in and billing records are protected by server-side checks instead. That is real isolation between customers, and it is not the same claim as “nobody at Dhaga can read it” — see below, where we say exactly who can.

Cloud AI calls (extraction, search answers, drafts, briefs, enrichment, card scanning) happen only when you press the button. Nothing runs in the background without you switching it on. On Dhaga Cloud those calls go to Anthropic on our API key and are metered to your plan in credits; on one of the single-tenant deployments we provision for enterprise customers, you bring your own key and we are not in the loop at all. Some short classification steps on Dhaga Cloud — routing an incoming chat message, a yes/no or pick-one judgment — are first asked of Jev, a model from TypeSafe (typesafe.ai): it sees the message or note text and the contact names and companies involved, and returns a typed answer rather than generated text. When Jev is not confident, the step goes to Anthropic as before. When you import a spreadsheet or file Dhaga does not recognise, Jev is also asked which contact field an unclear column holds: for the columns Dhaga could not place on your device it receives the column's name and up to five sample values from that column (never whole rows, and never values from two columns together). This happens only when you choose the file. A recognised export (Google, LinkedIn, vCard) sends nothing, and the “Read columns on my device only” switch on the import screen keeps every column on your device. Neither Anthropic nor TypeSafe trains its models on data sent through its API; TypeSafe keeps what it receives under its own policy. Scanned card photos are kept in your own database as visual receipts — a setting you can turn off, with one-click deletion of everything already stored.

The extension has no content scripts and no background scraping. While its side panel is open it reads your current text selection and checks the address of the active tab so it can offer the right options; reading a LinkedIn profile, taking a screenshot and its LinkedIn company search run only when you press their button, in your own tab. It sends exactly what you selected or captured, and only to the Dhaga instance you configured: for LinkedIn, the names, headlines and profile links of other people it read (mutual connections and company-search results) go to your instance only after you review them and press Add. Your instance sends captured text and screenshots to an AI model to extract the contact, and keeps a screenshot only if your store-captured-photos setting is on. There are no analytics inside the extension itself — the traffic measurement the Dhaga website runs is described under “What we measure on the site itself” below, and none of it ships in the extension.

Three kinds of information pass through Dhaga.

Your account. Your email address, your name if you give one, and either a password hash or the identifier from the provider you signed in with. We also keep the sign-in sessions you have open, including the IP address and browser description they were opened from, the plan you are on and the payment processor's identifiers for it, your settings, the phone number or chat identifier of any messaging app you link, and the record of what you agreed to at signup (described under “How your agreement is recorded”).

What you put in about other people. Contacts, notes, voice transcripts, photos of business cards and badges, follow-ups, meeting details, and the facts, relationships and search-index entries Dhaga derives from them. This is information about people who are not Dhaga users and have never dealt with us. You decide what goes in and what to keep about each person, and Dhaga uses it only to run the service for you (see “What never happens” below). If you are one of those people and have a question or concern, write to the contact at the end of this page.

Records of use. For each AI action we keep which feature ran, which model, how many tokens it used and what it cost, and when. That record holds no note text. If you send feedback through the in-app box, we keep your message, the page pattern you were on (never a record id), your screen size and browser description. The measurement the site runs on itself is described under “What we measure on the site itself”.

Each use below is tied to something you chose to do. Nothing here is a background feature you did not switch on.

• Running your account: signing you in, keeping sessions secure, limiting repeated attempts, and, where it is switched on, a bot check on the sign-in and sign-up pages.
• Capture and notes: storing the contacts, notes, transcripts and card photos you add, and turning them into the connections, facts and search index that make up your graph.
• AI features: extracting contacts and facts, answering your questions, drafting messages, briefs, enrichment and card reading, each when you press the button. Transcribing voice, where the instance has server transcription switched on; otherwise it happens in your browser.
• Calendar and contact sync: reading, and if you chose that, writing to Google Contacts and Calendar, only after you connect them. The Google sections below say exactly what.
• Messaging assistant: if you link WhatsApp or Telegram, reading the messages you send it, filing notes, answering, and sending replies and reminders back.
• Reminders and notifications: the emails described below — including a few product announcements a year, which you can unsubscribe from in one click — and browser notifications if you turn them on.
• Billing: charging for a plan, honouring refunds and reconciling our records with the processor.
• Referrals: if you arrive on an invite link, remembering the code until your signup so the reward can be granted.
• Measuring the site: counting page views and load times so we can fix what is slow. You can switch it off on the trust page.
• Support and fixing problems: answering what you write to us and looking at your account only to fix a problem you reported.

Where the law asks us to name a basis for using personal data, this is how we describe ours.

• To provide the service you asked for (your account, your graph, the features you use, billing): we need to use the data to do what our Terms promise.
• Your consent: the Privacy Notice box you tick at signup, and each connection or switch you choose yourself, such as Google, a messaging app or browser notifications. You can withdraw it (see “Withdrawing consent”).
• Our legitimate interests: keeping the service secure, preventing abuse, measuring how the site performs, and telling you a few times a year about significant new features in the product you use. You can object to the measurement with the switch on the trust page, and to product announcements with the unsubscribe link in each one or the switch in Settings.
• Legal obligations: keeping the financial records of payments.

Nothing connects itself. Both sit behind a button in Settings and stay disconnected until you press it, and pressing it asks you how much access you actually want before it sends you to Google — so the permission Google asks you to approve is the one you chose, not a maximum we ask for and then promise not to use.

Importing contacts reads the contacts you have saved, and only those — we deliberately do not ask for the scope that exposes addresses you have merely exchanged mail with. Those are not your address book and are not ours to read. Two-way sync — letting a correction you make here reach the phone in your pocket — needs the wider permission to change contacts, and it is one of the two answers you give when you connect. Choose to read only, and Dhaga asks Google for permission to see your contacts and nothing else; it could not edit your address book even if it tried. Changing your mind later means connecting the account again and picking the other answer.

Calendar asks the same question: free/busy only — the blocks where you are busy, never event titles, attendees or bodies — or the events themselves, which is also what lets Dhaga put follow-ups in your calendar. Even on the wider answer Dhaga writes only into a calendar it creates and names Dhaga; it is never granted permission over the calendars you already had, so it cannot edit or delete anything that was there before it arrived.

Who a meeting is with. Once you have turned on real event reading, Dhaga shows you an event's guest list when you open that event, and compares those addresses against the contacts you already have, so a meeting can show who it is with and a person's page can show when you last met. The comparison happens on our server and only on an exact address match. A guest who is nobody in your graph is shown to you, in your browser, on the event you opened — it is your meeting, and you were already sent that invitation — but they are still never stored, never written to a log, and never sent to an AI model. Dhaga never creates a contact from a guest list; someone becomes a contact because you added them. What is kept is the link itself — that a person you already had was on an event, with that event's title and time — and it is kept because remembering when you last spoke to someone is the whole point of the product. Deleting a contact deletes their links with them, and disconnecting the calendar deletes every link that came from it.

Dhaga's use of information received from Google APIs follows the Google API Services User Data Policy, including its Limited Use requirements. Concretely: your Google contacts and calendar data are used only to provide the features you connected them for, and they are never sold, never shared with anyone beyond the processors below, never used for advertising, and never used to train an AI model — ours or anybody else's. No human at Dhaga reads them except to fix a specific problem you have reported, or where security or the law leaves us no choice.

Disconnecting in Settings deletes the stored access and refresh tokens from our database at that moment, and Dhaga stops reading. Being honest about the limit of that: it does not withdraw the permission at Google's end, which you do at your Google account permissions. Contacts already imported stay in your graph, because by then they are your notes rather than a live copy of Google's — remove them the way you remove anything else here, and they go for good.

Facts and relationships always link to the note they came from. Deleting a note removes everything derived from it; “Forget this person” removes the contact and every trace — notes, facts, connections, search index entries, and their place in any group you put them in.

A note about a meeting is about everyone who was in the room. Forgetting one of those people removes their link to that note and everything it said about them, but it cannot delete the note itself — it is also somebody else's record, and erasing it would take their history with it. So that person's name can still appear in the words you wrote there. This has always been true of any note that mentions someone in passing; a shared note simply makes it easier to see. The alternative would be for us to rewrite what you wrote on a third party's behalf, which we are not going to do quietly. If you want the note gone, deleting the note itself still removes it and everything derived from it, for everyone on it.

If your employer puts you in a team workspace, everyone else holding a seat in it can open its members page and see your name, the email address your account uses, your role, and the day you joined. Not only the owner or an admin — every seat. This is new: the list used to be visible to owners and admins alone, and we changed it because a workspace you were placed into by an employer is a staff directory, and somebody who cannot see who runs it has nobody to ask for help.

That is the whole of what a colleague can see about you there. It is not a way into anything else: being in a team with someone — or being its owner or admin — gives nobody a read of your contacts, your notes, your facts or your follow-ups. Those stay yours, exactly as they were before you joined. What a colleague sees beyond the list is only what you deliberately share with them, contact by contact — and that sharing is switched off on Dhaga today, as the next section explains.

Two things stay with the people who run the workspace rather than with every seat: how many seats it has, and the invitations that have been sent and not yet accepted — an invitation is an address belonging to somebody who has not joined and may never.

This one is not switched on yet, and we are telling you before it is rather than after. Team workspaces are new, and sharing contacts inside one is turned off on Dhaga today. Here is exactly what it will do when it is turned on.

Sharing inside a team is per contact and opt-in — nothing of yours is visible to a colleague because you both work somewhere. There are two kinds. Sharing a contact with a named colleague gives that one person a read-only copy of the record and its notes. Adding one to the team directory shares far less: the company that person works at, and your name as the colleague who knows someone there. Never their name, email, phone, address, or anything you wrote about them.

When you leave that team, the directory entries keep your name. Everything you shared with a named colleague is deleted the moment you leave. The directory rows are not: they stay, still saying that you were the person who knew someone at that company. That is deliberate, because a directory that forgets who made the introduction is one nobody can act on — but it does mean an organisation you have left goes on holding your name against a company name. An owner or admin of that team can delete any of those entries, and you can ask them to. Being an owner or admin gives nobody a read of anyone's contacts, then or now.

Deleting your Dhaga account removes them too. Leaving a team and leaving Dhaga are different things, and they are treated differently on purpose: a leftover entry is for having moved on from a workplace, not for having closed your account. Delete the account and every directory row bearing your name goes with it.

Export your full graph as CSV, vCard, or JSON at any time. No lock-in is a feature.

There is no automatic expiry on your graph, and nothing deletes it when a plan ends or lapses. Your contacts, notes, facts, connections and search index stay until you delete them or delete your account. The periods below are the ones that are actually enforced.

• Deleting one thing: forgetting a contact, or deleting a note, removes what was derived from it (see above) from our live database immediately.
• Deleting your account removes, in one operation: your contacts, notes, facts, connections, search entries, groups, lists, follow-ups, calendar and contact-sync connections with their stored tokens, messaging links and chat history, saved connector credentials, settings, feedback you sent, referral records, sign-in sessions and the account itself.
• Calendar and contact connections: kept until you disconnect, which deletes the stored tokens at that moment.
• The chat assistant: it reads at most the last 7 days of your conversation. Its receipts for what it did are deleted by a daily job once they are 7 days old, and stored conversation transcripts by a daily job once they expire. Notes it filed for you are ordinary notes and stay until you delete them.
• Site measurement: the hash used to count a visit is discarded after 24 hours, as described under “What we measure on the site itself”.

Four things are not erased with the account, and we would rather say so than have you find out.

• Payment records. The record of each charge (amount, currency, status, plan and the processor's identifiers) is kept as a financial record. We have not set a deletion date for it.
• The administrative access log. Entries that name an account an administrator looked at stay in the append-only log. It holds identifiers and timestamps, never the contents of a graph.
• Organization records. If you used Dhaga inside an organization, the contacts that belong to the organization, and the notes you wrote on them, stay with the organization. Your personal workspace is erased.
• Backups. Dhaga Cloud keeps daily database backups. A deleted record leaves the live database at once and stays in a backup until that backup rotates. We have not yet confirmed the rotation window with our database host, so we do not state one.

Deleting an account is refused while a paid plan of your own is still active, so a subscription is never left billing an account that no longer exists: cancel the plan first, then delete.

On Dhaga Cloud, the credentials to the production database can read any row in it, and they are held by the people who operate the service — kept to the smallest number that can keep it running, and no wider. Pretending otherwise would be a lie: end-to-end encryption, where the operator holds only ciphertext, is incompatible with a product whose entire job is to read your notes and answer questions about them on a server. Anyone promising you both is describing something they haven't built.

So here is the actual boundary. Nobody at Dhaga opens your graph except to fix a specific problem you have reported to us, and only for as long as that takes. Not to see how the product is being used, not to build case studies, not out of curiosity, not for sales. The admin panel we run the business from shows accounts, plans and credit balances — it has no screen that displays anyone's contacts, notes or facts. Reaching those means going to the database directly, deliberately.

A note you write in an organization's workspace is not shared with your colleagues until you publish it — and the person who owns that organization can read it either way, published or not. That is a deliberate part of how organizations work, not an oversight, and we will not describe that state as “private” anywhere in the product, because it isn't. Your personal workspace is unaffected: nobody in your organization can see it, and copying a contact into the organization leaves your own record exactly where it was. Admins get no such access — only the owner.

Every visit to an administrative screen is written to an append-only access log — who, when, which screen, and which account they were looking at. We can't remove our own entries from it without that being a deliberate, visible act. It's the difference between a promise and a record, and it's the reason the paragraph above is checkable rather than just nice to read. The log holds identifiers and timestamps only, never the contents of anyone's graph.

We do not sell your personal information, share it with advertisers or for cross-context behavioural advertising, or hand it to anyone beyond the companies listed under “Who else touches it” without a legally binding demand — and if we get one and are permitted to tell you, we will. We do not train models on it, and neither do the AI providers we send it to. We do not read your graph for product research or aggregate it into anything, anonymised or not. New uses of your data get asked about first; they don't arrive in a changed privacy page.

Running Dhaga Cloud means a handful of companies necessarily process some of your data: the cloud host our database and app run on, the AI providers that answer your questions, classify your messages and, where it is switched on, transcribe your voice, the email service that sends your reminders, the payment processors, the bot check on the sign-in pages, and the traffic measurement our cloud host runs on the site itself, which the next section describes in full. Each gets the minimum needed to do its job. This table is the same list the trust page prints, with where each one holds the data.
Across borders. The regions in the table are where the data rests, so for most people using Dhaga Cloud it is processed outside the country they live in: the database is in Sydney, and the AI and email providers are in the United States. Payments are currently taken in Indian rupees by Razorpay, in India, for every customer; Stripe, which the table lists for customers outside India, is not currently used to take payments. We give 30 days' notice before a new company is added to the table. A single-tenant deployment, which enterprise customers arrange with us, removes all of them except whichever ones that customer chooses to configure.

Services you connect yourself are not in the table, because you choose them rather than us: Google, if you connect Contacts or Calendar; WhatsApp (run by Meta) and Telegram, if you link them, since your messages travel on their networks; and an enrichment provider such as Apollo, if you add your own key, which receives what you ask it to look up.

We measure how the site itself performs, on every page including the signed-in app. Two scripts from our cloud host do it: Vercel Web Analytics counts page views, and Vercel Speed Insights records how slowly pages actually loaded for real visitors. Between them they see the address of the page, the referrer that sent you there, roughly where you are, your browser and operating system, whether you are on a phone, tablet or desktop, and the loading timings themselves. That is the whole list.

Neither sets a cookie. Vercel counts a visit by hashing the incoming request rather than storing anything on your device, and discards that hash after 24 hours, so nothing accumulates into a profile of you — and with no cookie to ask you about, this section is the honest form of that disclosure rather than a consent pop-up. Neither can reach your graph either: they run in the page, not in the database, and are never handed a contact, a note, a search or an answer.

The one field that could have carried something is the address, since both scripts record the concrete one rather than the route pattern. So before either sends it, Dhaga strips the query string and replaces every record id with [id] — the same rule the in-app feedback box follows. What leaves your browser is /app/people/[id], never who, and never what you typed into a filter.

They load in production only, never in a development or preview build. And if you would rather not be counted, there is a switch: the trust page carries an off toggle that takes effect immediately, covers the in-app performance beacon too, and needs no account — because the person most likely to want it is reading that page without one. Nothing in the product needs these scripts to work. On a single-tenant deployment they are not part of the picture at all — the script they point at is served by Vercel's own platform, so on any other host it never loads and nothing is sent.

The paragraphs above are built to be checkable rather than merely promised: every administrative visit is written to the append-only access log, and every AI-derived fact links back to the note it came from, so what was done to your data leaves a record. And if you would rather not extend that trust at all, that is a supported choice: Dhaga can run on infrastructure you control, where we are not part of the picture — ask us about it on the contact page.

Signing up creates an account straight away — we store your email address, your name if you give one, and either a password hash or the identifier from the provider you signed in with. Verifying that address is what opens the account, so we also record whether it has been approved and when. You get an email asking you to confirm the address and one welcome email once the account is open; unsubscribe by replying.

A new account starts with its reminder emails switched on — the daily digest, pending confirmations, morning follow-ups, birthdays and anniversaries, and background-job alerts. All five are one switch each in Settings → Suggestions, they only ever go to your own address, and turning one off stops it immediately. The morning follow-ups switch also covers one short email shortly before a timed follow-up is due, which we send only if you have no messaging app linked to receive it there. Accounts created before 8 August 2026 keep whatever they had; nothing was switched on retroactively.

Occasionally — a few times a year — we email you about a significant new feature in Dhaga. They come from the founder, go only to your account's address, and are only ever about Dhaga. Every account gets them unless it opts out, and each one carries a one-click unsubscribe: the link at the bottom of the email, or the unsubscribe button your mail app shows. You can also turn product announcements off or back on any time in Settings → Suggestions. Unsubscribing takes effect straight away and changes nothing else — account emails such as address confirmation and password resets still arrive, and your reminder emails keep their own switches. All we store is whether, and when, you turned them off.

Card details never reach Dhaga — the payment processor handles them and we never see or store them. What we keep is the record of the charge itself: the processor's payment and subscription identifiers, the amount, the currency, the status, and which plan it bought. That's what lets us honour refunds, answer billing questions, and reconcile our records against the processor's.

Dhaga sets no advertising or tracking cookies and loads no advertising networks. This is everything it writes to your browser, from the same list the trust page prints.
Three more things are not in that table. A copy of your last graph and map view is kept in your browser's IndexedDB while you are signed in, so those views open without waiting for the network. It holds the same contact data the view shows, for one account and workspace at a time, and it is replaced or removed when a different account or workspace loads in that browser. Signing out does not clear it, so on a computer you share, clear this site's data in your browser when you finish. A service worker is registered only if you turn on browser notifications; it receives notifications and has no code to cache pages or data. A bot check from Cloudflare (Turnstile) loads on the sign-in, sign-up and password-reset pages when it is switched on for the instance. It runs under Cloudflare's own terms, receives your connection details and browser signals while it runs, and anything it stores on your device is Cloudflare's and not listed above.

The two page-measurement scripts are described under “What we measure on the site itself”.

Dhaga Cloud is for people aged 18 or older. Signing up asks you to confirm that you are, and we do not knowingly collect personal information from anyone under 18. That confirmation is a tick-box: we do not check anyone's age. If we learn that an account belongs to someone under 18, we will take steps to close it and delete its data. If you think that has happened, write to us at the contact below.

Signing up on Dhaga Cloud asks for three separate ticks: the Terms, this Privacy Notice, and that you are 18 or older. When the account is created through the signup page, our server records, on the account, when you accepted the Terms and which edition, when you consented to this notice and which edition, and when you confirmed your age. This is edition 2026-10-20 of this notice, last updated 20 October 2026. Accounts created before these boxes existed have no such record, and we have not invented one. When this notice changes materially we change its edition and date.

Depending on where you live, the law may give you rights over your personal data. This is what you can do and how.

• See and take your data: export your whole graph as CSV, vCard or JSON from Settings at any time, with no request to us.
• Correct it: edit any contact, note or fact in the app. For something you cannot change yourself, such as the email address on the account, write to us.
• Erase it: “Forget this person” on a contact, delete a note, or delete your account in Settings by typing your email address or the word DELETE. What survives is listed under “What survives deleting your account”.
• Object or limit: the measurement of the site has its own off switch on the trust page. To object to any other use, write to us.
• Nominate someone to act for you: where your law lets you name another person to exercise these rights on your behalf, write to us. This is handled by email; there is no form for it in the app.

For anything you have to ask us rather than do yourself, write from the email address on your account so we can confirm it is you, to the contact at the end of this page.

You agreed to this notice with a box at signup, and you may have switched on individual connections since. You can stop any connection yourself: disconnect Google or a messaging app, turn off reminder emails or product announcements, turn off browser notifications, or switch off site measurement. Dhaga has no separate switch that withdraws your agreement to this notice while keeping the account, because the service cannot run without the processing it describes. To withdraw it entirely, delete your account in Settings. Anything we did with your data before you withdrew stays done.

Write to us first, at the contact below, so we can try to put it right. You may also complain to your local data protection authority; in India, that is the Data Protection Board of India once it is operational.

Write to contact@ekasmi.com for any request in this notice, a question about your data, or a complaint. This is a company mailbox for Ekasmi TechLabs Pvt. Ltd., I-706, R10, Universe Avenue, Life Republic, Kolte Patil, Hinjewadi, Pune 411067, Maharashtra, India, not a named person. We acknowledge a privacy or grievance request within 7 days and resolve it within 30 days.