Privacy Policy

1. Who we are, and which role we are in

Strata is a chat widget that businesses embed on their own websites, operated by Few & Far LLC, a Texas limited liability company. You can reach us at lee.jungro@gmail.com. That gives us two distinct roles, and your rights depend on which one you are dealing with.

• We are the controller for our own account holders. If you signed up for Strata, use the dashboard, or browse strata.fyi, we decide what to collect and why. This policy is the full account of that.
• We are a processor for visitors to a customer's website. If you met Strata as a chat bubble on some other company's site, that company is the controller. They decide what the assistant is for, what knowledge it holds, and how long the record lives. We process on their instructions. This policy tells you what we technically do with the data. Their own privacy policy tells you why they collect it, and it governs.

Contact for either role: lee.jungro@gmail.com.

2. What we collect from account holders

• Account details: the email, name, organisation and workspace details you give us at signup.
• Your password, stored only as a bcrypt hash. We never store the plaintext and we cannot read it. There is no password reset flow yet, so a lost password currently needs us to fix the account by hand.
• A session cookie when you log in. It is signed, httpOnly, marked SameSite=None so the widget can call our API from a customer's site, and it lasts seven days. Two things worth knowing: the cookie is signed but not encrypted, so its contents include your email, role and workspace list in a readable form, and we keep no server-side session list, so a session cannot be cut short before those seven days elapse. Logging out clears the cookie in your browser.
• The content you load in: uploaded documents, FAQs, pages we crawl at your instruction, and the instructions you write for your assistant.
• Analytics on our own site: page path, referrer, coarse location and device type for visits to strata.fyi and the dashboard, through Vercel Analytics. This runs on our site only. It is not part of the widget and it does not follow you onto a customer's site.

3. What we process for visitors

If you are chatting with an assistant on a business's website, this is what reaches us. You do not need an account for any of it, and an anonymous conversation carries no account identity.

• Your messages and the assistant's replies, stored as a conversation.
• Contact details you choose to leave, for example the email or phone number you give when you ask for a human. Those go to the site owner's support queue. When the site owner answers, the reply is sent to your email address through our email provider, which is listed in section 6.
• A short list of remembered facts, behind a flag that is off by default. The assistant can carry a fixed, allowlisted set of facts between visits: name, phone, email, fulfilment preference, party size, and meal context. Nothing else. The feature is off unless someone explicitly turns it on, and as shipped today the widget reads that list without writing to it.
• Context from the page you are on. To act on a page rather than only talk about it, the assistant is sent its structure: headings, cart status, and the page's interactive controls, meaning the labels of buttons, links and form fields. When it is acting on the page that is up to about eighty controls. When it is answering a question it is up to twenty-five links with their URLs, thirty buttons and thirty fields, including the options in a dropdown. A shorter record, capped at forty of those controls, is written to the decision log described below.
• Some form field values. Values in fields identified as a password, passcode, one-time code, secret or API key are stripped in your browser and never leave the page. The assistant is told only that the field is filled. Other field values can be sent, truncated to forty characters, so the assistant can see what you have already typed. Do not enter payment card numbers or government ID numbers into a page while using the assistant.
• Page text, when you ask for it. Pressing "Read this page" sends the visible text of the page you are on to us, where it is stored and kept as part of that site's knowledge. This never happens on its own. A smaller page-text feature for developers also exists, and it is off unless someone explicitly turns it on.
• A document you attach in chat. If you are signed in on the site you are visiting, you can attach a file to the conversation. We extract its text, index it for that site's assistant, and it takes the same path as any other uploaded document, including the optional storage in section 6. It is held under your member identity rather than shown to every visitor; section 9 says how far that goes.
• Images, only behind a flag that is off by default. When enabled, the widget can send the URLs of product images on the page, and as a fallback a composite of visible images, to a model provider. There is no camera access and no screenshot of your screen.
• Your IP address, briefly. We read it to rate-limit abuse and hold it only in memory. We do not store it in our database. Our hosting provider keeps its own request logs, which is separate from this.
• A record of each action the assistant takes: what it was trying to do, the page URL, what it clicked, whether that worked, and which model answered. This is how a site owner audits what the assistant did on their site.

One flow is worth calling out on its own. If you use the microphone button, speech recognition is done by your browser, not by us. In Chrome and Edge that means the audio is sent to the browser vendor's speech service, under their terms rather than ours. If you would rather that not happen, type instead of speaking, and in particular do not speak a password aloud.

4. What the widget stores in your browser

The widget stores a small amount of data on the website you are visiting, under that site's own origin. None of it is used for advertising, and the widget sets no advertising or tracking cookies.

One thing does not fit that description, so here it is plainly. If you sign in or sign up through the widget, our session cookie is set: the one described in section 2, on our domain rather than the site's. It is marked SameSite=None so the widget can reach our API from whatever site you are on, which from that site's point of view makes it a third-party cookie, and it is sent with the widget's requests to us for the seven days it lasts. It carries your account identity, not a browsing profile, and it is set only if you sign in. Everything else below stays on the site you are visiting.

In localStorage, which survives closing the tab:

• strata_conversations_<site> and strata_last_conv_<site>: your list of past conversations on that site, and which one to reopen.
• strata_panel_size: the size you dragged the chat panel to.

In sessionStorage, which is cleared when you close the tab:

• strata_thread_snapshot_<site>: a copy of the recent transcript, so your conversation survives clicking through to another page.
• strata_turn_continuation_<site> and strata_agent_turn_<site>: a note that a request was in progress when the page changed, so the assistant can finish it. Both expire in minutes.
• strata_launcher_hidden_<site>: that you dismissed the chat bubble, so it stays dismissed for this visit.
• strata:pageCapture:<site>:<conversation>:<page>: a note that you asked the assistant to read a particular page, so the same unchanged page is not sent again.

All of it is there to make the chat work rather than to profile you. The widget also reads a small number of feature flags from this storage, which is how the off-by-default features in section 3 get turned on. Clearing site data for that website in your browser removes all of it.

5. Our legal basis for each of these

Under the GDPR and UK GDPR it is not enough to say what we do. We have to name the basis in law that lets us do it. Sections 2 to 4 say what we hold. This says why we are allowed to hold it.

• Performing our contract with you covers account details, the password hash, the session cookie, the content you load in, and running the assistant itself, including sending a turn to the model providers in section 6. Without these there is no account and no product to deliver.
• Our legitimate interests cover three narrow things, and in each case the interest is ours and we name it. Analytics on strata.fyi and the dashboard, so we can see which of our own pages are worth keeping. Abuse screening of questions, so a customer's assistant is not turned into a tool for harming someone. Security and error logging, including reading an IP address in memory to rate-limit, so the service stays up and we can tell what went wrong. We have weighed these against your own interests: none of them profiles you, none of them feeds advertising, and the analytics stays on our own site. You can object to any of them, and section 10 says how.
• A legal obligation covers only the case where the law requires us to keep or produce something, such as a record tied to a payment or a lawful request from an authority. It is not the reason anything else is still here. Section 8 says plainly that we run no automatic deletion, and that is a gap in our tooling rather than a retention duty.
• Consent is not a basis we rely on, and we would rather say so than imply a choice you were never offered. We set no advertising or tracking cookies. The features that are off by default are switched on by the business running the site, not by the person chatting, so it is that business that has to decide whether consent is needed for them.

On a customer's website none of this is ours to decide. That business is the controller, it picks the lawful basis for the assistant on its site, and it has to tell its own visitors which one it picked. We act on its instruction, and section 1 sets out the split.

6. Models and subprocessors

Strata answers questions using large language models we do not run ourselves. To produce a reply, your question, the recent conversation, the knowledge retrieved for it and the page context are sent to a model provider. There is no way to use the product without that happening. These are the companies involved:

Beyond that list, a business customer can point Strata at destinations of their own choosing. Where that happens, they chose the destination and we cannot vouch for it:

• Capabilities: an admin can register their own web endpoint. When it runs, we send the visitor's question, the recent conversation and a user identifier to that endpoint from our servers.
• A custom model endpoint: a workspace can send its inference traffic to any host it names, including one it runs itself.
• Website ingestion: our crawler fetches the pages an admin asks us to index, identifying itself as chat-widget-crawler/1.0.

Two flows happen in your browser rather than on our servers, so they are not in the table above. The first is fonts: the widget's stylesheet imports three families from fonts.googleapis.com, with the font files served from fonts.gstatic.com. Every visitor who loads a page carrying the widget therefore makes a request to Google carrying their IP address and browser details, with that site as the referrer. Google is not a company we contract with, we do not self-host the fonts yet, and there is no setting that turns this off. The second is the microphone, described at the end of section 3.

On training: Strata does not train models. We run no training pipeline, and no data you give us is used to build or tune a model, for you or for anyone else. What the providers above do with API traffic is set by their own terms, and we do not currently send them a no-training instruction with each request. If that distinction matters to your organisation, read the terms of the provider your workspace uses, or supply your own key so the traffic runs under your own contract.

7. Where data is processed

The database is hosted in AWS us-east-2, and our application runs in our host's default US region. Model providers process requests on their own infrastructure, in whatever locations their terms allow. Where a business customer has configured a capability endpoint or a custom model host, as described in section 6, that destination can be anywhere: they chose it, and we do not control where it runs. We do not offer EU or UK data residency today.

If you are in the EEA, the UK or Switzerland, your data is transferred to the United States. We have not yet executed standard contractual clauses or certified under a transfer framework. If you need a transfer agreement in place before using Strata, ask us and we will handle it individually rather than point you at a page that does not exist.

8. How long we keep it

Plainly: there is no automatic expiry today. We run one scheduled job and it deletes nothing. Conversations, documents, contact details left in a support queue, and the record of assistant actions persist until they are deleted.

What can be deleted, and how, is uneven, so here it is exactly. An admin can delete an individual conversation or an individual document from the dashboard. There is no control for deleting a single support-queue entry or a single line of the assistant action log: those go when the whole workspace is deleted, which removes everything belonging to it. If you ask us to erase one of them on its own, we do it by hand against the database. The action log is also not tied to the conversation it came from, so deleting a conversation leaves those entries, which include the opening of what was asked and the page it was asked on, until they are removed separately.

We would rather say that than publish a retention schedule we do not enforce. Automatic expiry is something we intend to add. Until it exists, deletion on request is the mechanism, and section 10 explains how to ask.

9. Who we share it with

We do not sell personal information, and we do not share it for cross-context behavioural advertising. We have never done either. We disclose data to the subprocessors in section 6, to the business customer whose site you used, and where the law requires it.

Data is separated by workspace: every query we run is scoped to the workspace whose widget you are using. That scoping is done by the queries our application makes, not by the database underneath, which has no row-level rules of its own.

Separation between people inside one workspace is weaker, and we would rather say so than let you assume otherwise. On the public chat route your member identity is not verified against your signed-in session, so the private documents and remembered facts held under it are not protected from someone else reaching that same workspace. A session whose role is owner, admin or staff can retrieve any member's private documents in that workspace as well, and that role is read from the cookie without checking which workspace it was granted in, so it applies on whichever workspace's widget that person is talking to. Treat what you attach or tell the assistant while signed in as private from other visitors, not as protected from an administrator or from someone setting out to read it. Within a site, a link to a conversation is itself the key to that conversation, so treat one as private rather than as something to pass around.

10. Your rights, and how to use them

If the GDPR or UK GDPR applies to you, you have the right to access your data, correct it, have it erased, restrict or object to how it is processed, and receive a copy in a portable form. You also have the right to complain to your data protection authority.

If you are a California resident, you have the right to know what we collect and why, to have it deleted, to correct it, and to opt out of sale or sharing. As above, there is nothing to opt out of, because we do neither. We will not treat you differently for asking.

To exercise any of these, email lee.jungro@gmail.com. We aim to respond within 30 days. Two practical notes:

• Tell us enough to find the record. Anonymous chats are not tied to a name. The website you used and roughly when you used it is usually enough. We will ask for more if we cannot locate it, and we will not ask for more than we need.
• If you chatted on another company's site, that company is the controller and the fastest route is to ask them directly. You can still write to us: we will act on their instruction, delete when asked to, and tell you what happened.

11. Security

Passwords are hashed, session cookies are signed and rejected if tampered with, and keys you give us are never returned by any API, including to you. We hold no security certification: no SOC 2, no ISO 27001, no HIPAA, and no third-party penetration test on record. Security sets out what we do and do not have, in more detail and to the same standard of honesty.

12. If something goes wrong

If personal data is exposed, we will tell affected customers without undue delay after becoming aware of it, with what we know at the time rather than a polished account weeks later. Where we act as a processor, we notify the business customer so they can meet their own obligations to their visitors. We do not name a fixed notification window here, because we have not built the monitoring that would let us meet one reliably, and a deadline we cannot hold is worse than none.

13. Children

Strata is a business product and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child's data reached us, write to us and we will delete it.

14. Changes to this policy

When this changes, we update the date at the top. For a change that materially affects what we collect or who receives it, we will tell account holders by email before it takes effect. Adding a subprocessor counts as material.

15. Contact

For anything on this page, including rights requests and questions about a specific conversation, email lee.jungro@gmail.com. A real person reads it.