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, with every table row-level-security-scoped to your account so one signed-in user cannot read another's rows. 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. Anthropic does not train on data sent through its API. 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 accesses the active tab only at the moment you click its icon, sends exactly what you selected, and only to the Dhaga instance you configured. No content scripts, no background scraping, and 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.

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.

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.

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.

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 data, share it with advertisers, or hand it to anyone 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 does the AI provider 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 provider that answers your questions, the email service that sends your reminders, the payment processors, 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: the payment processors never see your graph, the email service only ever sees your own address, and the measurement scripts see pages and timings rather than anything in them. A single-tenant deployment, which enterprise customers arrange with us, removes all of them except whichever ones that customer chooses to configure.

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. Dhaga Cloud is invite-only while it's in beta, so we also record whether your account has been approved yet. You get one email confirming you're in the queue and one when you're approved; 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. Accounts created before 8 August 2026 keep whatever they had; nothing was switched on retroactively.

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.