Privacy Policy

Who we are and how to contact us

Herb Alert is operated by [to be supplied: full legal entity name, entity type, and country/state of incorporation], of [to be supplied: registered postal address for legal notices].

For the purposes of the UK GDPR and the EU GDPR, that entity is the data controller for the personal data described in this policy. For the purposes of the California Consumer Privacy Act, it is the business that determines the purposes and means of processing.

You can reach us about anything in this policy, including any request to exercise your rights, at support@herbalert.net.

[to be supplied: whether a Data Protection Officer has been appointed, and if so their name and contact details. If no DPO is required, this sentence should be removed rather than left ambiguous.]

[to be supplied: whether an EU representative under GDPR Article 27 and/or a UK representative under UK GDPR Article 27 has been appointed, and their contact details. This is required if the operator has no establishment in the EU or UK but offers the service to people there.]

What this policy covers

This policy covers the Herb Alert website, the Herb Alert mobile applications, and the interfaces they use to reach our servers.

It does not cover any third-party website or product you reach by following a link from Herb Alert. Those services have their own privacy policies and we do not control them.

Information we collect

We collect the following categories of information. Most of it exists only because you chose to create it.

• Account identity. Sign-in is handled by Firebase Authentication, which is Google's service, and your email address is held there rather than by us. Every request your device makes carries a signed sign-in token; our servers read your account identifier from that token, together with your email address and whether it has been verified, in order to work out whose data to return. What we store is the account identifier. We do not store your email address - the Herb Alert database has no column for one - and we do not store the token. If you sign in with Google, the fields Google provides are listed under "Signing in with Google" below. If you sign in with an email address and a password, the password is set and verified by Firebase Authentication and is never received or stored by Herb Alert.
• Conditions you follow. The health conditions and topics you choose to follow, and how you have labelled each one - for example whether a condition was diagnosed by a clinician, is self-assessed, is a symptom you are recording without claiming a diagnosis, or is being followed on behalf of somebody else.
• Substances you track. The herbs, supplements and other substances you save or track.
• Your experiences and notes. Free text you write about taking something. The note you attach to a condition and the private narrative of an experience report are encrypted by our servers before they are written to storage. The remaining fields of an experience report are not: how long you took something, what else you were taking at the time, any adverse effects you record, any conflict of interest you declare, the outcome you chose, and the condition and preparation the report is about are all stored as ordinary readable text alongside your account identifier. See "How we protect information" below.
• Notification preferences. Which alerts you want, and a registration record for each device on which you turn notifications on. For the device we store a one-way hash of the push token rather than the token itself, together with a platform label - so the record identifies the device to us without our holding the credential that addresses it.
• Subscription and billing status. Whether you hold an active subscription, what it entitles you to, and when it expires or renews. Payment card details are never received by Herb Alert; see "Payments and subscriptions" below.
• Consent records. Which version of these terms and of this policy you accepted, and when, and whether you have consented to publish an experience to the community.
• Locale and time zone, so dates and reminders make sense to you.
• Technical and security information generated when you use the service. For each request our servers record an event name, which part of the service handled it, a randomly generated request identifier, the route path that was called, the HTTP status, how long it took, and an error code when something fails. Alongside those they record opaque record identifiers - the identifier of a notification, a device registration, a catalogue entry, a background job - so a fault can be traced to the record it happened on. They do not record the text you type into search, your notes, your narratives, your email address, or any authentication token. Herb Alert's own code never reads or stores your IP address; Cloudflare, which serves every request, necessarily receives it in order to deliver and protect the connection, and handles it under its own terms. These records are written to Cloudflare's Workers Logs. We configure no export of them and keep no copy of our own, so how long they survive is Cloudflare's platform retention and nothing else. Cloudflare publishes that as seven days on the Workers Paid plan, which is the plan this service runs on, and three days on the free plan; seven days is the documented maximum on any plan. After that Cloudflare deletes them and we have nothing left to look at.

Information we do not collect

We do not collect payment card numbers. We do not collect your password. We do not buy personal information about you from data brokers, and we do not build advertising profiles.

We do not use an analytics or product-measurement service. There is no analytics library, tag manager, pixel or beacon in the Herb Alert website or in the mobile applications, no usage event is generated or sent to anybody, and no identifier is attached to one, because none exists. We also use no third-party error-monitoring or crash-reporting service. What we know about how the product is used, we know from the server logs described above.

Herb Alert does not connect to medical records, pharmacy systems, insurers or health providers, and nothing you record here is added to any medical record.

Signing in with Google

If you choose to sign in with Google, Google asks for your permission and then tells us that the sign-in succeeded, along with the account information you approved.

Herb Alert requests exactly three OAuth scopes and no others: openid, https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/userinfo.profile. All three are non-sensitive scopes. Between them they tell us your email address, whether Google has verified it, the identifier Google uses for your account, and basic profile information - your name and your profile picture if you have one. We request nothing that reaches any other Google service.

We use that information for one purpose: to create and identify your Herb Alert account, so that the topics you follow and the notes you write come back to you and to nobody else. We do not use it for advertising, we do not sell it, and we do not transfer it to others except to the service providers listed in this policy who operate the service on our behalf.

Signing in with Google does not give Herb Alert access to your Gmail, your Google Drive, your contacts or your calendar.

You can disconnect Herb Alert from your Google account at any time in your Google account permissions settings. Disconnecting stops future sign-in through Google; it does not by itself delete your Herb Alert account. To delete the account and its contents, use the deletion path described below.

How we use your information

We use the information described above only for these purposes.

• To provide the service - to authenticate you, to show you the conditions and substances you follow, and to store and return your notes and experiences.
• To send the notifications you have asked for, according to your notification preferences.
• To surface safety and interaction warnings relevant to what you follow.
• To operate subscriptions - to determine what your account is entitled to and for how long.
• To publish an experience to the community, but only when you have separately and explicitly consented to publish that specific experience.
• To keep the service secure and working - to prevent abuse, investigate faults, and protect against fraud and unauthorised access.
• To understand in aggregate how the service is being used, from the server logs described above, so we can decide what to improve.
• To comply with legal obligations, and to establish, exercise or defend legal claims.

Our legal bases for using your information

If you are in the United Kingdom or the European Economic Area, we must have a lawful basis for each use of your personal data. Ours are as follows.

• Performance of a contract (UK/EU GDPR Article 6(1)(b)) - creating and running your account, storing what you save, delivering the features your subscription entitles you to, and providing customer support.
• Consent (Article 6(1)(a)) - sending push notifications, and publishing an experience to the community. You can withdraw either consent at any time, and withdrawal is as easy as giving it. Withdrawing consent does not affect processing that already happened while the consent was valid.
• Legitimate interests (Article 6(1)(f)) - keeping the service secure, preventing abuse and fraud, understanding aggregate product usage, and moderating content submitted for publication. We have weighed these interests against your rights and have concluded they do not override them; you can object to processing on this basis at any time, as described under "Your rights" below.
• Legal obligation (Article 6(1)(c)) - retaining records we are required to retain, and responding to lawful requests.

Health information and special category data

The conditions you follow and the experiences you write about taking a substance are information about your health. Under the UK and EU GDPR that is special category data (Article 9), which requires a further condition on top of a lawful basis.

We rely on your explicit consent under Article 9(2)(a). You give that consent when you choose to record a condition, a substance or an experience. If you publish an experience to the community, that is a separate and additional explicit consent, given for that specific act of publication.

You are never required to record a health condition to use Herb Alert. The catalog can be read without saving anything.

Health information is also sensitive personal information under California law, and Herb Alert limits its use to providing the service you requested, as described in "California privacy rights" below.

What becomes public if you choose to publish

Nothing you write is public by default. Your notes, your narratives, the conditions you follow and the substances you track are private to your account.

You may separately choose to publish an individual experience to the community. If you do, that experience is reviewed by moderation and published in a de-identified form. Your private narrative is not published.

Once something is published, other people can read it, and you should assume that anyone who can read it may copy it. Withdrawing a publication removes it from Herb Alert going forward; it cannot retrieve a copy somebody else has already made.

If you delete your account you can choose, at that moment, to withdraw your published experiences at the same time.

Understand how public this is before you use it. A published experience is readable by anyone. It is served by an interface that requires no account and no sign-in, so it is not confined to Herb Alert members, and a search engine that runs page scripts can reach and index it. Publishing an experience is publishing to the open internet, not to a members' area.

How we share information

We do not sell personal information and we do not share it for cross-context behavioural advertising. We share it only in the following circumstances.

• Service providers who operate the service on our behalf, under contract, and only for that purpose. Every one that appears anywhere in the Herb Alert codebase is named here. Cloudflare provides the compute, the databases, the object storage and the vector search the service runs on, and - through Workers AI - the model that embeds a search query, as described under "Artificial intelligence" above. Google provides Firebase Authentication for sign-in, and Firebase Cloud Messaging for push notifications. Apple and Google process subscription purchases made through their app stores, and Stripe processes any subscription bought on the web. There is no analytics provider, no email provider, and no error-monitoring provider, because the product uses none. We have searched the whole of Herb Alert's code and configuration for others: there is no support desk, no ticketing system, no CRM, no live-chat widget and no outbound mail service connected to any part of it, so no third party receives your information through one. [to be supplied: the provider that hosts the support@herbalert.net mailbox this policy directs you to. No mail service of any kind appears in the product's code or configuration, so whoever operates that mailbox sits outside it - and they will handle whatever a person writes in, which can include a rights request describing their health. That provider belongs on this list. So does anyone else who can reach personal data without any code calling them, such as a contractor with database access.]
• Other users, but only for an experience you explicitly chose to publish, and only in its de-identified published form.
• Legal and safety disclosures, where we are required by law to disclose information, or where disclosure is necessary to investigate suspected fraud or abuse, to enforce our terms, or to protect the rights, safety or property of any person. Where we are permitted to tell you about such a request, we will.
• A successor in a merger, acquisition or sale of assets, in which case your information would remain subject to this policy until you are given notice of any change and a chance to act on it.

Artificial intelligence and automated processing

Herb Alert uses language models to build the catalog: to segment and read published research, to pull structured claims out of it, to write the summaries you see on a card, and to check a written card back against the claims it came from. All of that runs on published literature and on documents our own editorial team supplies. None of it runs on your account.

Your notes and your experience narratives are never sent to an AI or large language model - not for moderation, not to de-identify them, and not for search. When you write an experience, Herb Alert suggests which substances you seem to have mentioned so you can confirm them. That suggestion is not made by a model: it is a word match against our public catalog of substance names, aliases and botanical names, run inside our own server, with no network call and no model of any kind. The narrative never leaves that server, and the encrypted note attached to a condition is never processed at all.

The de-identified version of an experience that appears in the community is not generated by a model. It is the text a human reviewer approves for publication.

One thing you type does reach a model, and we would rather say so plainly than bury it. When you search the catalog, the words you typed are sent to an embedding model - a model that turns text into a list of numbers so that passages about the same subject can be found - so that the search can match on meaning and not only on exact words. The model is Cloudflare's Workers AI, running on the same Cloudflare network that already runs the rest of Herb Alert; the query is not sent to any separate AI company. It is used to answer that one request. We do not keep a history of your searches, we do not attach a search to your account, and the search text is not written to our logs. Searching does not require an account, and the model is never given your notes, your narratives, or anything else from your account - only the words in the search box.

Cloudflare publishes its position on what it does with that text, and it is worth quoting rather than paraphrasing. Cloudflare states that it "does not use your Customer Content to (1) train any AI models made available on Workers AI or (2) improve any Cloudflare or third-party services, and would not do so unless we received your explicit consent", and that it does not make that content available to any other Cloudflare customer. The words you type into search are Customer Content in that sense. Two further things follow from how we have set this up: the model we call is one Cloudflare hosts itself rather than one it passes on to another AI company, so your query does not leave Cloudflare's network, and we do not route it through Cloudflare's AI Gateway, which is the Cloudflare product that would otherwise record prompt text by default.

[to be supplied: how long Cloudflare itself holds the text of a query sent to Workers AI, if at all. Its published data-usage page commits clearly on training but states no retention period for inference inputs, and makes no affirmative statement that it does not store them. That is a genuine gap in the public documentation rather than something this policy can settle by reading the code, and it should be confirmed with Cloudflare rather than assumed either way.]

We do not make decisions producing legal or similarly significant effects about you by automated means alone.

Cookies and browser storage

Herb Alert sets no cookies. Neither the website nor our servers write a cookie of any kind, so there is no advertising cookie, no tracking cookie and no session cookie to tell you about. What the website does use is your browser's own storage, and the following list is all of it.

• Your theme choice, stored in local storage under the name nh.theme. It records whether you picked the light theme, the dark theme, or chose to follow your system setting. First party. It has no expiry, and nothing in the product ever removes it - not even signing out - so it stays until you clear your browser's data for this site.
• Your signed-in session, stored in the browser's IndexedDB by Google's Firebase Authentication library, under names beginning firebase:authUser: and firebase:persistence:. It holds the tokens that keep you signed in between visits. First party to herbalert.net. It has no expiry and is removed when you sign out. If your browser cannot use IndexedDB, the same entries go to local storage instead.
• A Firebase software-version record, stored in a separate IndexedDB database called firebase-heartbeat-database. The Firebase library writes it and reports a summary of it to Google on sign-in requests, so that Google knows which versions of its own software are in use. The storage is first party; the information goes to Google. This is the one item in this list that is not strictly necessary for Herb Alert to work. The library prunes it to roughly thirty days, and nothing in Herb Alert removes it.

Third-party sign-in windows, opt-out signals and analytics

Signing in with Google opens a window on Google's own addresses, and the Firebase library loads a sign-in helper from a Google-operated domain rather than from herbalert.net. Anything those Google pages store is set by Google under Google's own policies. Herb Alert cannot read it and does not control it.

Herb Alert does not detect the Global Privacy Control signal or a Do Not Track header. Neither is read anywhere in the website or the applications. California requires an opt-out preference signal to be honoured where it applies to a sale of personal information or a share for cross-context behavioural advertising; Herb Alert does neither, so there is no sale and no share for such a signal to opt out of. If that ever changes, the signal will be honoured, and this policy will say so before the change takes effect.

[to be supplied: a decision, for each jurisdiction the service is offered in, on whether a consent notice is required before the Firebase software-version record above is written. The EU and UK ePrivacy rules require consent for storage that is not strictly necessary, and that record is the only item in the list that is arguably not necessary - the theme preference and the sign-in session are, and the service sets no cookies at all. This is a legal determination, not a technical one.]

Push notifications

Notifications are off by default, on every channel. Nothing is sent to you until you turn them on.

When you turn them on, your device is issued a push token by its platform. We do not store that token. We store a one-way hash of it and a label saying which platform the device is - enough to recognise the device, not enough to reconstruct the credential that addresses it. Delivery is through Google's Firebase Cloud Messaging and the push service built into your device.

The wording of a notification is deliberately uninformative, because a lock screen is not private. By default it says only that a research update is available for a topic you follow: it does not name the topic and it never names a substance. Only if you separately turn on previews does the notification name the condition. Nothing else about you travels with it - the message carries an identifier for the matching item in your in-app inbox and a flag recording whether the preview was included.

You can turn notifications off at any time in your Herb Alert notification preferences, or in your device's system settings.

Herb Alert does not send email. There is no mail service connected to the product at all: no transactional email, no digest, no newsletter, no marketing. If you receive a message asking you to verify your address or to reset your password, that is sent by Google's Firebase Authentication at the moment you ask for it, and not by us. Because we operate no mailing list, there is nothing to unsubscribe from. The data export described below is never emailed to anybody.

Payments and subscriptions

Subscriptions purchased on mobile are processed by the Apple App Store or the Google Play Store. Those stores collect and process your payment details under their own privacy policies. Herb Alert does not receive your card number.

What we receive and store is your entitlement status - whether a subscription is active, what it covers, and when it renews or lapses - so the service knows what your account can access.

A subscription can also be bought on the web. That purchase happens on a checkout page hosted by Stripe: you enter your card details on Stripe's page, not in Herb Alert, and no card number is ever received, transmitted or stored by us. What Stripe reports back is the identifier of the subscription, its status, and the date it renews or lapses. We store those three things and nothing else about the payment. Herb Alert does not store your card, your billing address, or a Stripe customer record.

Stripe is the payment processor for that web route, and the only one: Stripe's is the sole payment API this product calls. To open a checkout session we send Stripe the identifier of the price you are buying and an encrypted form of your account identifier, so that the resulting subscription can be matched back to your account. We do not send Stripe your email address, your name or your address. Anything you type on Stripe's own checkout page you are giving to Stripe directly, under Stripe's privacy policy rather than this one.

Buying on the web is switched off by default, as every paid feature is, and no such purchase can be made until it is explicitly turned on. [to be supplied: who the merchant of record is for the web route, and whether web checkout will be switched on at publication. If it will not be, the three paragraphs above should be removed rather than left to describe a route nobody can take.]

How long we keep information

We keep your account information and the content you save for as long as your account exists, because that content is the service. When you delete your account, or when a retention period below expires, we delete it.

[to be supplied: retention period for an inactive account - after how long without a sign-in is an account treated as dormant, is the user warned first, and is it then deleted or anonymised.]

[to be supplied: retention period for the security and abuse-prevention records that are not the request logs described under "Information we collect" - those sit in Cloudflare's Workers Logs and their retention is stated there. What still needs a period is the material we hold ourselves, in particular the abuse reports a reader files about published community content.]

[to be supplied: the window within which deleted data is purged from encrypted backups and from any replica, and confirmation of what that window actually is in Cloudflare D1 and R2 as configured. Backups routinely outlive a deletion request and the policy must say so honestly rather than implying instant erasure everywhere.]

[to be supplied: retention period for the deletion audit stub, and for any billing or tax record that must be retained by law after an account is deleted.]

[to be supplied: retention period for moderation records relating to content that was reviewed or removed.]

Exporting your data

You can request a copy of your data from your account at any time. The export is a single JSON file containing your profile, the topics you have saved with their notes, your research preferences and follows, your research inbox, your experience reports including private narratives, and your entitlements and consent history.

The export is downloaded by your own signed-in session and the download request expires. It is not emailed to anybody and it is not published behind a shareable link.

Requesting an export requires you to have recently signed in, so that somebody with momentary access to an unlocked device cannot extract your health information.

Deleting your account

You can delete your account from within the app. It takes effect immediately: there is no waiting period, no grace period and no way to undo it. Deleting your account requires you to have recently signed in, for the same reason an export does.

Deletion destroys the free text you wrote. Your notes and your experience narratives are erased, the edit history of your experiences is deleted outright, your profile record is deleted, every device registration is deleted, and the stored copies of your recent requests are deleted - all but one, the record of the deletion request itself, which is kept so that a repeat of that request is answered rather than carried out again. Your sessions are revoked and the account is marked deleted, so no token issued to it is accepted again. By default your published experiences are withdrawn from the community at the same time; you can choose to leave them published, in which case the de-identified text stays up while everything private to you is still destroyed.

Be clear about what is not destroyed, because "delete" is often used loosely. Records tied to your account identifier remain in our database after deletion: which conditions you had saved and how you had labelled each one, the non-narrative fields of your experience reports - the outcome, how long you took something, what else you were taking, any adverse effects and any conflict of interest you declared - which preparations those reports named, your subscription entitlements, your consent history, and your in-app inbox items, which stop being delivered. Those records no longer have a profile, a device or any free text attached to them, but they are not anonymous, and they describe health topics. Separately, a single audit row records that an account with your identifier was deleted; it holds no health content.

Deleting your Herb Alert account does not delete your Firebase Authentication account, which is Google's record of your sign-in, and we do not delete it on your behalf. You can still sign in to Google or to Firebase afterwards; Herb Alert will simply refuse the session. If you signed in with Google, disconnect Herb Alert in your Google account permissions to sever that link.

Deleting your Herb Alert account does not by itself cancel a subscription purchased through the Apple App Store or the Google Play Store. Cancel the subscription in the store that sold it.

How we protect information

Personal notes and narratives are encrypted before they are stored. The cipher is AES-GCM, with a fresh random nonce for every value and a key that can be rotated, applied by our servers as the text arrives; the stored column holds ciphertext rather than readable text.

That is encryption at rest under our control, and we will not describe it as more than it is. It is not end-to-end encryption. The key is a secret held by our servers, not by you and not by your device. Your text reaches us in readable form over an encrypted connection, and our servers can decrypt it - which is how it comes back to you when you open the app, and how it gets into your data export. It follows that we could be compelled to produce it, and that anyone who obtained both the database and the key could read it. If you want to record something that no operator can ever read, do not put it into a hosted service, this one included.

The encryption covers the note attached to a condition and the narrative of an experience report. It does not cover the rest of that report - the outcome, the duration, the other treatments, the adverse effects, the declared conflict of interest - nor which conditions you follow and which preparations you record. Those are stored as ordinary readable text next to your account identifier.

There is one more place your text is held, and it gets the same protection. So that a save which is interrupted and retried cannot be applied twice, our servers record the response to a write and replay that recorded answer if the same request arrives again - and for a note or an experience narrative, that response contains the text you just saved. The recorded copy is sealed with the same AES-GCM cipher, the same rotatable key and the same fresh-random-nonce-per-value scheme as the column it came from, so what sits in storage is ciphertext and not readable text. If sealing were to fail, the copy is discarded rather than written in the clear: you still get your answer and the save can simply be retried. If a sealed copy can no longer be decrypted - because the key that sealed it has been rotated out, for example - the retry is refused rather than carried out a second time. The single exception is a local development environment with no encryption key configured, which records the copy as readable text and holds no real account's data.

These recorded copies are deleted when you delete your account, apart from the one recording the deletion request itself, which is kept so that a repeated deletion request is answered rather than carried out again. [to be supplied: how long a recorded write response is kept for an account that has not been deleted. Nothing in the request path expires one; the code provides a pruning routine with a suggested thirty-day horizon, but no scheduled job runs it today, so a retention period has to be both decided and actually scheduled before this section can state one.]

Traffic between your device and our servers is encrypted in transit. Sign-in is handled by Firebase Authentication rather than by a password store of our own. Actions that expose or destroy your health information, such as an export or an account deletion, require a recent sign-in.

No service can promise perfect security, and we do not. If you believe your account has been compromised, contact support@herbalert.net.

[to be supplied: the breach notification commitment - the timeframe within which affected users and the relevant supervisory authority will be notified. GDPR sets 72 hours to the authority, but the user-facing commitment should be stated deliberately.]

Herb Alert holds no security certification and has had no independent security audit. There is no SOC 2 report, no ISO 27001 certification and no HIPAA compliance programme, and this policy will not imply otherwise. The protections described in this section are what there is.

International transfers

Herb Alert runs on Cloudflare and uses Firebase Authentication from Google. Both operate global networks, which means your information may be processed on servers outside the country you live in, including in the United States.

Where personal data is transferred out of the United Kingdom or the European Economic Area, we rely on appropriate safeguards for that transfer.

[to be supplied: the specific transfer mechanism relied on - the EU Standard Contractual Clauses, the UK International Data Transfer Agreement or the UK Addendum, the EU-US Data Privacy Framework and its UK extension - and confirmation that each named sub-processor is actually covered by the mechanism claimed.]

Every one of our Cloudflare databases and object storage buckets sits in Cloudflare's Eastern North America region, which is where the data they hold is stored, and none of the databases has read replication switched on, so no second copy of one is kept in another region. That is a placement preference for storage; it is not a legal jurisdiction restriction, and no jurisdiction restriction is configured on any of them. The vector search index is described separately here for a reason: Cloudflare exposes no region setting for that product at all, so we cannot honestly state one for it. What it holds is catalog text and the numbers derived from it, never anything from your account. Cloudflare's network itself serves your requests from wherever you happen to be. [to be supplied: the region configured for the Firebase Authentication project, which is set by Google and does not appear anywhere in this product's own configuration.]

You can ask us for information about the safeguards that apply to a transfer by writing to support@herbalert.net.

Your rights in the UK and the European Economic Area

If you are in the UK or the EEA, you have the following rights over your personal data. You can exercise any of them by writing to support@herbalert.net, and several are available directly in the app.

• Access - to be told whether we hold personal data about you and to receive a copy of it. The in-app export provides this immediately.
• Rectification - to have inaccurate personal data corrected and incomplete data completed. Most of what we hold is editable directly in the app.
• Erasure - to have your personal data deleted. The in-app account deletion provides this. Some records may be retained where the law requires it, and we will tell you if that applies.
• Restriction - to have us limit how we use your data while a dispute about its accuracy or our use of it is resolved.
• Portability - to receive the data you provided to us in a structured, commonly used, machine-readable format, and to have it transmitted to another controller where technically feasible. The JSON export is provided for this purpose.
• Objection - to object to processing based on our legitimate interests, on grounds relating to your particular situation.
• Withdrawal of consent - to withdraw a consent you gave, at any time, without affecting processing already carried out under it. Turning off notifications and withdrawing a publication are both withdrawals of consent.
• The right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects.

Making a complaint

If you are unhappy with how we have handled your personal data, please tell us first at support@herbalert.net so we have a chance to put it right.

You also have the right to complain to a data protection supervisory authority. In the United Kingdom that is the Information Commissioner's Office. In the EEA it is the supervisory authority of the country where you live, where you work, or where the issue occurred.

[to be supplied: the lead supervisory authority for the operator, if the operator is established in the EEA or UK, and the address to which a complaint should be directed.]

We respond to rights requests within the period the law requires - one month under the UK and EU GDPR, extendable where a request is complex, and 45 days under California law, extendable once.

California privacy rights

If you are a California resident, the California Consumer Privacy Act as amended by the California Privacy Rights Act gives you specific rights. This section describes them and states what Herb Alert does.

In the twelve months before the date of this policy, we collect the categories of personal information described in "Information we collect" above. In CCPA terms these are: identifiers (your account identifier, and your email address, which we read from your sign-in token to identify you but do not store); commercial information (subscription and entitlement status); internet or network activity (the request records described under "Information we collect"); and sensitive personal information, being information about your health. We do not collect geolocation. Our own code neither reads nor stores your IP address, so we hold no IP-derived location about you.

We collect that information from you directly, from your device, and from Firebase Authentication when you sign in. We use it for the purposes listed in "How we use your information", and we disclose it for a business purpose only to the service providers listed in "How we share information".

We do not sell personal information, and we have not sold personal information in the preceding twelve months. We do not share personal information for cross-context behavioural advertising. Because there is no sale and no sharing, there is nothing to opt out of - but if that ever changes, this policy will be updated and an opt-out will be provided before the change takes effect.

We use sensitive personal information only to provide the service you asked for, and not to infer characteristics about you. That means the right to limit the use of sensitive personal information is already satisfied by default.

You have the right to know what we collect and why, the right to a copy of it, the right to correct it, the right to delete it, and the right not to be discriminated against for exercising any of these rights. We do not offer financial incentives in exchange for personal information, and exercising a right will not degrade the service.

To exercise a right, use the export and deletion controls in the app, or write to support@herbalert.net. We will verify a request by confirming control of the account it concerns.

[to be supplied: the process for an authorised agent to submit a request on a consumer's behalf, and whether a toll-free telephone number must be provided given the operator's size and how it interacts with consumers. Businesses that operate exclusively online and have a direct relationship with the consumer may provide an email address instead, but that determination should be made deliberately.]

[to be supplied: confirmation of whether the operator meets the CCPA applicability thresholds at all. If it does not, this section should say that these rights are offered voluntarily rather than implying a statutory obligation.]

Other United States privacy rights

Several other US states - including Virginia, Colorado, Connecticut, Utah and Texas - give residents rights to access, correct, delete and obtain a copy of their personal data, and to opt out of targeted advertising, sale, and certain profiling. Herb Alert does not conduct targeted advertising, does not sell personal data, and does not profile users for decisions with legal or similarly significant effects.

Where those laws require consent before processing sensitive data including health information, we rely on the consent you give when you choose to record a condition, a substance or an experience.

To exercise any of these rights, write to support@herbalert.net.

[to be supplied: whether an appeal process is required for the states that mandate one - Virginia, Colorado, Connecticut and others require a documented appeal route when a rights request is refused - and what that process is.]

Children's privacy

Herb Alert is not directed to children. The service is intended for people aged 16 and over, and we do not knowingly collect personal information from anyone under 16.

If you believe a person under 16 has given us personal information, contact support@herbalert.net and we will delete the account and its contents.

That requirement is stated, not verified, and you should know which. Herb Alert does not ask your date of birth and operates no age gate and no age declaration. Creating an account requires an email address and a password, or a Google sign-in, and nothing else; there is no point in the sign-up or onboarding flow at which age is asked or checked. We rely on the requirement in the terms, and on acting when we are told or discover that an account belongs to somebody under 16.

[to be supplied: whether a higher minimum age applies in any jurisdiction the service is offered in. GDPR permits member states to set the digital consent age anywhere from 13 to 16, and some app store and regional rules impose their own minimums.]

Affiliate links

Affiliate product links are built into Herb Alert but are switched off. No affiliate provider is enabled, and no credentials for one are configured, so no product link is shown and no request is made to any merchant today. What follows describes what the feature does when it is switched on, so that this section is not silent about code that already exists.

The product search happens on our servers, not in your browser, and the only thing sent to the merchant is search wording built from our own catalog - a substance name and its preparation. No account identifier, no condition, and nothing you have written is ever sent to a merchant. Product details that come back are cached against the catalog entry, in the public catalog database, not against you. An outbound product link is stripped down to the merchant's address, the product path and the affiliate tag before you are sent to it, so no context about your visit rides along. Herb Alert does not record that you clicked one: there is no click tracking, no redirect through us, and no per-user product event anywhere in the code.

Affiliate links are not switched on when this policy is published. Three separate things would each have to change before one product link could appear: the feature flag for a merchant, which is off and for which no setting is stored at all; a per-merchant permission record, of which none exists; and the merchant credentials, which are configured in no environment. Until all three are in place nothing is shown and no merchant is contacted. If that changes, this section and the terms of service will be completed before it does, and the compensation disclosure the US Federal Trade Commission requires will be stated in the terms at the same time.

Changes to this policy

We may update this policy as the service changes or as the law requires. The effective date and last updated date at the top of this page always reflect the current version.

If a change materially affects how we use information you have already given us, we will give you notice before it takes effect - in the app, or by contacting you - and, where the law requires your consent to the change, we will ask for it rather than assume it.

[to be supplied: the notice period given for a material change to this policy, and the mechanism used to give it.]

Contact us

Questions, requests and complaints about this policy or about your information all go to the same place: support@herbalert.net.

Postal address for formal legal notices: [to be supplied: postal address for legal notices.]