Terms and policies
Privacy policy
What is collected, why, who else sees it, how long it stays, and what you can ask us to do about it.
Version2026.08.24-1Last updated24 August 2026
Who is responsible
HappyChases Media Works OPC Private Limited operates FirstBrief and decides what personal data it collects and why. Under India's Digital Personal Data Protection Act 2023 that makes us the Data Fiduciary and you, as the person the data is about, the Data Principal.
- Registered office
- Kursi Cowork, 3rd Floor, LK Logistics and Corporate Park, Raipur, Chhattisgarh 492015, India
- GSTIN
- 22AAFCH1697E1ZR
- Data Compliance Officer
- [email protected]. The same person is the grievance officer for the purposes of the Consumer Protection (E-Commerce) Rules 2020, and the same address serves both. See contact for what to write and when we answer.
The DPDP Act is the regime this policy is written against, alongside the Information Technology Act 2000 and the SPDI Rules 2011. Where the law and this page disagree, the law wins.
The short version
- You can read the archive without an account. No sign-in means no account and nothing recorded about you.
- Analytics is off until you say otherwise. We would like to use Google Analytics. It does not load, contacts nobody, and sets no cookie unless you accept it — see cookies. There is no advertising, no remarketing, no session recorder and no third-party embed of any kind. The fonts are served from our own machine.
- Our error monitoring is our own. Sentry runs on infrastructure we control, not on somebody else's service — §6.
- We never sell or share your data, and we never send it to a language model. The models read government documents; they are never told who is reading.
- We never see your card. Payments go through Razorpay and no card, UPI or bank credential ever reaches our servers.
- You can erase your account yourself, immediately, from your account settings.
- Nothing else is deleted on a schedule. That is a real gap and §9 says so rather than describing a policy we do not run.
What we hold, and why
This is the complete list. Every row is a field in our database, and there is nothing collected that is not on it.
- Email address
- It is how you sign in and where a brief is sent. Confirmed before anything is delivered to it. Required — there is no account without one.
- Password
- Stored only as a salted hash. We cannot read it, and neither can anybody who takes a copy of the database. Not held at all if you sign in with Google.
- Display name
- Optional, and only what you type. Blank unless you fill it in.
- Time zone and jurisdiction
- So the morning brief arrives in the morning where you are, rather than where our servers are.
- Delivery preferences
- Whether you want the immediate alert and the morning brief, and what hour the brief should go out.
- What you follow
- The regulators, departments and sectors you subscribe to, and which sector page you came through when you added one — so we can tell a deliberate choice from an incidental one when offering you a newly added body. Also the bodies you were offered and declined, so we do not ask twice.
- Which circulars you have opened
- One row per circular, the first time you open it, with the timestamp. It does two jobs: it marks a row as read so you can see what is new to you, and it is what the free allowance is counted against. Because it records the first opening only, re-reading never costs a second allowance.
- This is a reading history. It is the most sensitive thing here — what a company reads about tells you what a company is worried about — and it is not shared with anyone, not used for advertising, and never sent to a language model.
- When you last looked at your feed
- A single timestamp, so that “new since you were last here” means something.
- What we have sent you
- One row per email: which circular, which channel, whether it sent or failed, when, and the message id Resend gave it. It exists so that a retry cannot send you the same circular twice, and so that “did we ever send this?” has an answer.
- Subscription and payment records
- Which tier, whether it is active, the period it runs to, the amount, a reference from the payment processor, and whether a mandate is registered. No card number, no expiry, no CVV, no bank account number and no UPI credential exists anywhere in our systems — there is no field for one.
- Google account details
- Only if you sign in with Google. We ask for two scopes — your basic profile and your email address — and store the profile response Google returns, which typically includes your name, your email address, whether Google has verified it, your profile picture URL and your locale. We do not ask for offline access, so we hold no token that could be used when you are not signing in, and we can never read your Gmail, your files or your calendar.
Why this section is a list rather than a paragraph: “we may collect information such as…” is how a policy avoids committing to anything. If something is not on this list, we do not have it.
What we do not hold
- No IP addresses and no user agents in the application. Nothing in the product records either. A web server or a network provider in front of it will see an IP, as one does for every site on the internet; nothing in FirstBrief stores one against you.
- No location beyond the time zone you set yourself.
- No advertising or profiling identifiers.
- No payment instrument details — see the row above. Not the last four digits, not a card fingerprint, nothing.
- No contact list, no calendar, no files. Nothing on the service asks for them. If a feature is ever built that would, this page changes before it ships, not after.
Cookies, what the browser stores, and the choice you have
Strictly necessary — no choice is offered, and none is hidden
These exist because the product cannot work without them. They stay on this site, they are read by nobody else, and no consent is asked for them. They are listed here because disclosure is owed even where a choice is not.
- sessionid
- Set when you sign in; it is what keeps you signed in. Not readable by JavaScript, sent only to this site, and marked secure in production. Lasts two weeks unless you sign out.
- csrftoken
- Protects forms against being submitted from another site. It is deliberately readable by the page, because the page has to echo it back — that is what the protection is. It contains no personal data.
- fb-theme, fb-consent, and one return address
- Not cookies: three values held in your browser's own storage and never sent to us. Your light/dark setting; the choice you made below, so we do not ask again; and — briefly, only if you create an account from a circular — the address of the circular you were reading, so that confirming your email can return you to it. The last is read once, then erased, and expires by itself after three days.
Analytics — off unless you accept it
We would like to use Google Analytics 4 to count visits and see which pages are read. It is a transfer to Google: your visit, the page, the referrer and the device details a browser sends leave our infrastructure and are processed by Google as our processor, and Google sets its own cookies on your device.
We send nothing to Google, and set no analytics cookie, unless you agree. That is meant literally. The Google tag is not in the page, not deferred and not pre-connected — it does not exist until a stored acceptance says it may, and then it is created by the page. This is deliberately stronger than the usual arrangement, where the tag loads on every page view and then reads a consent signal; that still contacts Google, and it is the contact you have not agreed to.
- _ga, and _ga_ followed by a stream id
- Google's cookies. They identify a browser, not a person, and they last up to two years. Set only after you accept, and deleted by us when you withdraw.
- Your choice, and how to change it
- Recorded on your device under fb-consent, with the date and the version of the categories you were shown. It is never sent to us — a cookie would arrive here on every request, which would make refusing cost you more data than accepting. “Cookie choices” in the footer of every page reopens it, and withdrawing takes one click, exactly as accepting did. When we change what the categories cover we ask again rather than treating an old yes as permanent.
- With JavaScript turned off
- Nothing loads and no banner appears. The default is the safe state: the analytics tag is created by the same script that would have asked you, so a reader without JavaScript is never counted and is never shown a control that cannot work.
No Google Analytics measurement id is configured on this deployment, so the analytics option does not appear at all and nothing has ever been sent to Google. The mechanism is described here because it is built, and it is described as a choice because it can never run without one.
Errors and performance — Sentry, on our own machines
Sentry is not a third party here, and the distinction is material. Companies usually mean sentry.io, which is a processor like any other. Ours runs at sentry.happychases.com, on infrastructure this company controls, in the same estate as the database. Nothing captured by it is shared with Sentry the company or with anybody else, so it sits with the strictly necessary tier rather than with the processors in §7: it exists to keep the service working and secure.
That position only holds if it is not collecting people. So personally identifying capture is turned off — Sentry's send_default_pii setting stays false, which means the SDK does not attach the signed-in user, the client IP address, cookies or request bodies to an event. What is captured is the error, its stack trace, the route and method, the release, and timing spans for the frontend, the API, the background workers and the database queries a request touched.
A stack trace can still contain data by accident. Local variables are captured with a frame, and an exception raised while handling one person's request can carry that person's address in a variable or in an error message. That is the residual risk, it is not zero, and it is why events are held on our own machines.
Stated precisely, because the alternative is worse: no error monitoring is running in this build, and no event has been captured from it. This section is the configuration it runs under, and if send_default_pii is ever set true, this page is wrong from that day and has to change before it does.
Who else processes it
Five, and no others. Each is named with exactly what reaches it. Sentry is not on this list, for the reason §6 gives.
- Resend — email
- Sends the morning brief and the immediate alerts. Each send hands Resend your email address, the subject line and the message body, and nothing else — no name, no user id, no reading history, no list membership. We do not keep a mailing list with them; who should receive what is decided here and Resend is the pipe. We store the message id they return.
- A language model provider — summaries and relations
- Government document text and its metadata only. A request contains the issuing body's name, the document's title, its publication date and its text — the same public document anyone can download from the regulator — and is made once per document when it is ingested, before any reader has seen it.
- No personal data is ever in one. Not your address, not an identifier, not what you follow, not what you have read. Enrichment runs on the ingestion path, where no reader exists to be named, and the function that makes the call takes no user argument at all. Which provider serves it is a deployment setting: the software speaks to Anthropic directly and to any OpenAI-compatible host, which is how it currently reaches DeepSeek through OpenRouter.
- Razorpay — payments, mandates and invoices
- Takes payments, registers the mandates that recurring debits run under, and issues GST invoices. You enter your card, UPI or bank details on Razorpay's own page. No card, UPI or bank credential ever reaches our servers — there is no field for one in our schema and no code that would receive one. What comes back to us is a payment reference, a status, an amount and whether a mandate is registered.
- Nothing about you has reached Razorpay. No payment has been taken from anybody, so no call has ever been made from this system.
- Google — sign-in, and analytics if you accept it
- Sign-in: only if you choose it, and only at the moment you sign in. Google learns you signed in to FirstBrief; we learn the profile fields listed in §3. If you never press the Google button, Google is not involved at any point.
- Analytics: a separate matter, under a separate choice, described in §5. Property FirstBrief, a web stream on firstbrief.in, with Google acting as our processor. Nothing is sent unless you accept.
- Hosting and network
- The application, the database, the queue and the Sentry instance run on servers this company rents and administers, orchestrated with Coolify — not on a managed platform that reads the data. The domain is to be served through Cloudflare, which, once it is, will terminate TLS and therefore see the network metadata of every request — the IP address, the URL and the browser's own headers — as any network in front of a website does. Nothing in FirstBrief stores any of it.
We do not sell personal data, share it for advertising, or transfer it to anybody not named above. If that changes, it changes on this page before it changes in the software.
Where it is stored, and how it is kept safe
In a PostgreSQL database on infrastructure we run ourselves, reachable only over a private network, with the database, the queue and the cache all bound to internal interfaces. Passwords are stored only as hashes, and the database is the only copy — there is no file store, no data warehouse and no third-party backup service holding a second one.
These are the reasonable security practices the Information Technology Act 2000 and the SPDI Rules 2011 require of us: transport encryption, hashed credentials, no service exposed that does not have to be, access limited to the people who operate the system, and the address-scrubbing filter §11 describes applied to every log line.
Our processors run their own infrastructure and may process data outside India: Resend, Google, Razorpay and the language-model host each operate internationally. Razorpay settles in India.
How long it is kept
Honestly: for as long as your account exists, and there is no automatic deletion today. No retention job runs. Reading history, delivery records, subscription rows and expired sessions all accumulate and are removed only when an account is erased or when we are asked to remove them.
That is a gap rather than a design. What we intend, and what we will implement and then describe here rather than the other way round: expired sessions cleared on a schedule; delivery records kept long enough to stop a duplicate send and then aged out; reading history kept while it is serving you and no longer.
Payment records are the exception, and it is a legal one. Books of account under the Companies Act, records under the Income-tax Act and the GST rules all run for years past a transaction, and none of them is discharged by a request to be forgotten. So when an account is erased, what you follow, what you have read, what you declined and what we sent you go with it, and the payment records stay — attached to a row that no longer identifies anybody. That is how the DPDP Act's erasure right and the tax law's retention duty are both kept at once, and §11 sets out exactly what falls on each side.
Your rights, and how to use them
Under the DPDP Act you can ask us for a summary of the personal data we hold about you and what we have done with it; to correct or complete anything inaccurate; to erase it; and to withdraw consent. You can also nominate somebody to exercise these rights if you die or become incapable of doing so yourself.
To use any of them, write to [email protected] from the address on your account. We answer within thirty days.
You can erase this account yourself, from your account settings. It happens immediately, it cannot be undone, and the page lists exactly what is removed and what is kept before you confirm. There is one case it refuses: an account with a live subscription, because a payment mandate cannot be cancelled from inside the product and erasing the account would leave one running with nobody behind it. Revoke the mandate in your bank or UPI app, or write to us, and we will erase it.
Withdrawing consent to analytics is one click, from “Cookie choices” in the footer of any page — the same one click that gave it.
There is no self-service download. Ask us by email and we will send you what we hold.
Some things you can already do yourself: change your delivery preferences and what you follow on the account page, and unsubscribe from any email using the link in it — which works without signing in, one click, and needs no reason.
If we have not dealt with you properly, tell us first, and then, if you are still not satisfied, you may complain to the Data Protection Board of India.
Known weaknesses, stated rather than omitted
A policy that left these out would be technically true and practically dishonest. Three that were listed here have been fixed and are described as fixed rather than quietly removed.
- Fixed: you can erase your own account. Immediately, from the account page, with no grace window and no email exchange — account settings. What goes: your reading history, what you follow, what you declined, your confirmed addresses and every session. What stays: payment and subscription records, for the statutory period, attached to a row whose address, name and password have been destroyed and which nobody can sign into.
- Fixed: the unsubscribe link no longer carries your account number. It names your account by a random value that means nothing outside our database. It is still signed, so it cannot be forged, and it still never expires — that is deliberate, because an unsubscribe link that has quietly stopped working leaves you with no way out. Anybody you forward one of our emails to can still use it to switch that one kind of mail off; they cannot sign in, read your history, or change anything else.
- Fixed: a failed send no longer writes your address to our log. It records the account number and the domain part of the address, which is what tells us a whole mail provider is rejecting us. A filter removes anything address-shaped from every log line as a second line of defence.
- Still true: nothing ages out on a schedule. Reading history, delivery records and expired sessions accumulate for as long as your account exists. Erasing your account removes them.
- Still true: we cannot cancel a subscription for you. A mandate is revoked in your own bank or UPI app, which is what a mandate is for, or by writing to us. It is also the one thing that makes erasure refuse.
- Still true: your consent record is only on your device. We keep no copy, which is the more private arrangement and also means we cannot produce a ledger of who consented to what. We think that is the right trade for a signed-out reader; it is a limit and it is named here rather than glossed.
Children
FirstBrief is a professional tool and is not directed at children. We do not knowingly hold data about anyone under 18. If you believe we do, tell us and we will remove it.
If something goes wrong
If personal data is exposed, we will notify the Data Protection Board of India and every affected person as the DPDP Act requires, and we will say what happened, what was exposed and what we have done — rather than what the incident is being called.
Changes
The version and date at the head and foot of this page are the version and date of this text. A change that materially affects what we do with your data will be emailed to account holders before it takes effect, and where it changes what the cookie categories cover you will be asked again rather than held to an older answer.