Last updated: August 2026
We built ThouShaltNotClick to protect people, not to exploit them. In the ThouShaltNotClick browser extension, your email is analyzed on your device and the content never leaves it. You may also opt in, per email, to deeper AI analysis; our AI partner stores nothing. We keep body text in four narrow cases — a report you submit, an email the AI judges dangerous, an admin telling us we scored one wrong, and short phrases lifted out of confirmed phishing so our detector learns them — each described in detail below. When AI catches a phishing attack, only the sender and subject are shared with your organization. If you use the support chat on this site, what you type goes to our AI provider to compose the reply and the transcript is stored — that too is described below. We use one privacy-first analytics tool, configured cookieless and anonymous, and signed-in student sessions are excluded. We will never sell your data to anyone, ever. This isn't a legal loophole — it's a promise.
Footnote: we also publish a separate Outlook add-in, currently in beta. Microsoft's add-in platform cannot run our analyzer on the device, so it sends up to 3,000 characters of the open email to our servers to be scored. The on-device statement above describes the browser extension; details on the add-in are below.
| Data | Why | Stored Where |
|---|---|---|
| Name & email | Your account | Our secure servers (encrypted at rest) |
| Password | Authentication | Bcrypt hash only — we never see your password |
| Simulation results | Track if you caught or clicked the phishing test | Our server |
| Training progress | Know which courses you completed | Our server |
| Extension install status | Help admins see who has protection active | Our server (yes/no + last seen) |
| Online Kindness stats | Aggregate counts of polite language signals | Your device + server (aggregate only, daily sync) |
| AI Analysis data (opt-in only) | Deeper phishing analysis when you click the AI button | Sent to our AI service in real time; it stores nothing. We log the score and verdict. Body text is kept only when the AI scores the email below 30 — see “AI-Enhanced Analysis” below. |
| Reported emails (you press Report) | So your admin can judge what you flagged | Sender, subject, link URLs, message headers, and a 500-character body excerpt. The excerpt is erased after 30 days. |
| Phishing samples (AI score below 30) | Learn how attacks are written; improve detection | Up to 3,000 characters of body, with your own name and addresses stripped out. Filed under the sender. Visible only to TSNC platform admins. Erased 30 days after that sender was last flagged. |
| “You missed this phish” reports | Admin-only: tell us our scoring got one wrong | Sender, subject, and a 500-character body excerpt — only when an admin chooses to send it. Excerpt erased after 90 days. |
| Learned phishing phrases | Teach the detector the wording attackers reuse | 3-to-5-word fragments of the subject and 500-character excerpt of reports an admin confirmed as phishing, kept with the IDs of the source reports and organizations — no sender, no recipient, no reporter. Identifying details are removed before the fragments are cut. See “Learned Phishing Phrases” below. |
| Support chat on this website | Answer your question; hand off to a human if asked | What you type, our replies, your IP address and browser string — and, if you ask for a human, the name, email and note you enter. Sent to Anthropic to compose each reply. Deleted after 90 days unless you escalated to a human, in which case it is kept. |
| Community threat alerts | Protect your org when AI confirms a phishing attack | Sender, subject, and the AI's written explanation — no body text |
| Org email domains | Recognize emails from colleagues (familiar sender detection) | Domain names only — cached locally on your device |
When you open an email in Gmail, our extension analyzes it for phishing indicators using a local analysis engine (analyzer.js) that runs entirely inside your browser. The email content is never transmitted to our servers or any third party. The trust score, findings, and recommendations are all computed on your device.
Footnote — the Outlook add-in (beta). We also publish a separate Outlook add-in, currently in beta. It does not work the way the extension does: Microsoft's add-in platform gives us no way to run our analyzer on your device, so when you open the TSNC panel on an email the add-in sends the sender, subject, link URLs, and up to 3,000 characters of the body to our servers, where the same scoring engine runs. That is its normal, default behavior every time you open the panel — there is no separate opt-in for it. We score the message and return a verdict; the body is not written to our database on this path. The cases where body text is stored are listed below and apply to the add-in exactly as they apply to the extension. The on-device statement above describes the browser extension.
When you install our extension, Chrome tells you it can “read and change all your data on all websites”. That is accurate — the extension requests access to every site, not only Gmail and Outlook — and you should hear it from us rather than discover it in the manifest. Here is why, and what it does not mean.
The full permission-by-permission breakdown is on our Security page.
When you press Report Suspicious, we send and store more than metadata, so here is the full list: the sender address, the subject, the link URLs, the message headers (up to 16 KB), and a 500-character excerpt of the body. The excerpt exists so your administrator can review what you flagged without having to ask you to forward the email. It is visible to administrators at your organization. The excerpt is erased 30 days after the report; the sender, subject and verdict remain. Two follow-on notes that belong here rather than in fine print: if an administrator confirms the report as phishing, short fragments of that excerpt — with identifying details removed first — are kept separately as detection signals (see Learned Phishing Phrases below), and the 30-day erasure is a sweep rather than a timer (see How the Erasures Above Actually Run). Report Safe sends the sender and subject only.
You may optionally click the “AI Analysis” button on any email's trust badge for a deeper, AI-powered review. This is entirely voluntary and requires your explicit action each time — it never happens automatically. When used:
A clear disclaimer (“Email content was sent to our AI for this analysis”) is shown every time you use this feature.
Your organization's email domains (e.g. yourschool.edu) are synced to the extension so it can recognize emails from colleagues. This only includes the domain names — no staff names, email addresses, or other data. Internal senders receive a small trust score boost. This runs locally in your browser using the cached domain list.
When AI analysis identifies an email as clearly dangerous (score below 30/100), the sender address and subject line only are stored in our database and shared with other members of your organization. This protects your colleagues from the same phishing attack.
The Online Kindness Score monitors your communication patterns across email, chat, and AI platforms for polite language signals (such as greetings, gratitude, and considerate phrasing). This analysis runs 100% in your browser. Your actual messages, emails, and conversations are never recorded, transmitted, or stored. Only an aggregate kindness grade (Average, Good, or Excellent) is synced daily to the server for organizational leaderboards if you are part of an organization. Organization administrators can disable this feature for their organization.
When you manually scan a suspicious URL, that URL is sent to our server for real-time threat analysis — similar to how Google Safe Browsing works in every web browser. The URL is processed immediately and never stored, logged, or associated with your account. No page content, browsing history, or personal data is included.
Administrators have a button to tell us our scoring got one wrong — that a real phishing email slipped through with a good score. Because we cannot diagnose that without seeing what we mis-scored, that report includes the sender address, the subject, our scores, and a 500-character excerpt of the body. This is the third of the four places we hold body text. It is never automatic — an administrator has to choose to send it — and it goes only to ThouShaltNotClick's own engineering team, never to another school. The excerpt is erased 90 days after the report — longer than the 30 days we give a staff report, because this queue is reviewed by hand and infrequently. Administrators who would rather not include the excerpt should describe the email in words instead.
Attackers reuse wording. When an administrator marks a report as confirmed phishing, we run its subject and its 500-character excerpt through a phrase extractor and keep the most distinctive 3-to-5-word fragments, word for word, as candidate detection signals. This is a fourth store of body text and it belongs on this page as much as the other three.
The chat bubble on thoushaltnotclick.com is answered by an AI assistant, not a person, and it is not a local feature — it is the one place on this site where what you type is sent to a third party as you type it.
We would rather describe the mechanism than let “erased after 30 days” imply a precision we do not have. The 90-day support-chat delete runs on a daily scheduled job. The three body-text erasures — report excerpts at 30 days, phishing samples at 30 days from the sender's last flag, missed-phish excerpts at 90 days — are not on a timer. Each is a sweep that fires when the matching part of the product is used: submitting a report sweeps the report excerpts, filing or reviewing a phishing sample sweeps the sample corpus, and submitting or opening the missed-phish queue sweeps that one. Each sweep is throttled to at most once an hour.
In practice that means content past its window is erased within about an hour of the next time anyone touches that surface — usually the same day. On a genuinely idle system it can sit longer. What we will promise without qualification is that every sweep re-counts what should be gone and raises an alert if anything remains, so a retention promise cannot fail silently — and that you can always ask us to purge something immediately at privacy@thoushaltnotclick.com. Putting these three sweeps on the same daily schedule as the chat delete is queued work.
Schools may optionally enable a Content Filter that blocks categories of websites on managed devices. It is off by default — most users are never affected. When a school turns it on, the extension blocks sites locally on the device (your browsing is not sent to us to be filtered) and records policy events only: attempts to reach a blocked site, and staff “proceed anyway” bypasses (domain + category + time), shown to administrators as aggregate counts by default. It does not record your general browsing — sites that aren't blocked are never logged. Full terms are in the Content Filter Addendum.
We use one third-party analytics tool — PostHog — and we run it locked down: cookieless (no tracking cookies, so no consent banner), anonymous by default (we never attach your name or email to analytics events), no session recording ever, and it honors your browser's Do Not Track setting. Signed-in student sessions are excluded entirely. That's the whole list. No Google Analytics. No Facebook Pixel. No ad networks. No data brokers. No advertising or marketing trackers of any kind. You can verify this yourself: the analytics configuration is plain, readable source in our web app, and the browser extension ships no analytics at all — its privacy commitments are embedded directly in the source code of every file.
For schools using ThouShaltNotClick, we store organizational data necessary to run phishing simulations and training: staff rosters (name, email, role), campaign results, and training completion records. This data is accessible only to authorized school administrators and is never shared with other schools, organizations, or third parties.
Organization-wide benchmarking (e.g. Diocese-wide) uses anonymized, aggregated statistics only — click rates and catch rates averaged across schools. No individual staff member's data is ever visible to other schools or the parent organization.
You can request complete deletion of your account and all associated data at any time by contacting us. School administrators can remove staff members from their roster, which removes their simulation and training data. Online Kindness data is stored locally on your device and can be cleared by removing the browser extension. Community threat alerts you contributed will be removed when your account is deleted.
SMS verification is an optional security feature. We send text messages only when you have explicitly opted in from your Security Settings page by ticking a standalone consent checkbox. SMS opt-in is never a requirement for using ThouShaltNotClick — you can use the platform without it.
What we send. One-time 6-digit verification codes when you log in or perform sensitive actions on your account. We do not send marketing, promotional, or bulk SMS messages of any kind. Message frequency varies based on how often you log in — typically a few messages per month per active user. Message and data rates may apply per your carrier's plan.
What we store. Your phone number is stored only while SMS verification is enabled on your account. We also record the date and IP address of your initial opt-in (TCPA compliance) and the version of the consent text you agreed to. Phone numbers are never sold, rented, or shared with third parties for marketing.
How to opt out. Reply STOP to any verification message — your number is immediately removed and SMS verification is disabled. You can also disable SMS verification from your Security Settings page. Reply HELP for help. We will never charge you to opt out, and we will never message a number that has opted out without a fresh, explicit opt-in.
SMS messages are delivered through Twilio, our verified communications partner. For full SMS program details, see the SMS Verification Policy.
A ThouShaltNotClick school account is created with staff coverage only, and in that default state we store no student names, no student email addresses, and no student records of any kind. The core platform — phishing simulations and staff training — is built for adult staff and teachers.
Student coverage is a separate add-on — either purchased, or granted to your school under a contract with us. No student record is created anywhere in our system unless both of the following are true. Neither one alone is enough, and if we cannot verify either one, we store nothing:
Both are checked on every path that could store a student's name, by one shared gate. There are two such paths: a directory sync, which additionally requires an administrator to have designated a specific directory group as a Student group; and a parent invitation, where a parent creating their account types their child's first name, last name and grade so the school can link them. If the gate refuses the parent path, the parent's own account is still created normally and the child's name is discarded before it is written anywhere — including our logs, which record the refusal but never the name.
There are three different things that can exist for a student, and they hold very different amounts of data. Conflating them is the sort of thing a privacy policy should not do, so here they are separately.
0. The parent-invitation link. The smallest of the three: a parent's account, the child's first name, last name and grade as the parent typed them, and the school it belongs to. Nothing else, and no login for the child.
1. The roster record (what a directory sync creates). For each student in a designated Student group we store first name, last name, school email address, and grade level, plus whether the record is still active. That is the complete list for a roster record. It has no login, no password, and no activity attached to it. We do not collect student browsing history, message or email content, grades, test scores, academic records, disciplinary records, location, biometric data, or device identifiers.
2. The student account (only if your school issues students their own logins). A student account is a real account, and it accumulates what any account accumulates. It is not limited to the four roster fields. Alongside their name and school email it can hold:
If that last point is not what your school wants for students, the controls are yours: do not issue student logins, or do not deploy the extension to student devices, or turn Online Kindness off for your organization.
Phishing simulations: staff by default, students only if your administrator turns them on. Simulations are addressed to the staff target list. Student participation is a separate decision that belongs to your school's administrator and is off by default for every organization — we do not enable it, and it does not switch itself on because a student appears on a roster. In this release there is no control in the admin interface to turn it on: the setting ships in the off position and the screen for changing it comes in a later release. When it does arrive and a school turns it on, students get their own campaigns on their own send volume — set independently of the staff cadence — drawn from a separate pool of templates an administrator has marked age-appropriate. That pool starts empty, and adult-financial lures (payroll and direct-deposit changes, wire transfers, vendor and invoice fraud, tax, benefits, banking and W-2 scams) are refused for student recipients even if someone tags one of them age-appropriate.
One honest caveat, because the alternative is a promise we cannot yet keep: historically a student could be enrolled in a staff campaign by accident, simply by being on the roster a campaign was built from. We are removing that. The check that identifies students and holds them out of staff campaigns — and that refuses to launch at all rather than guess when it cannot tell who on a roster is a student — is in place on the main campaign-launch path, and we are extending it to the remaining automatic campaign-generation paths. Until that is finished we will not claim that no student is ever enrolled by accident. If you want certainty in the meantime, keep student accounts off the target roster your campaigns are built from, and write to privacy@thoushaltnotclick.com if you think a student received a simulation — we will tell you what happened.
Student coverage is governed by additional terms — the Student Coverage & Student Data section of our Organization Terms of Service — which apply on top of the base agreement and set out the school's consent obligations before any student is added.
Separately, some schools deploy our optional Content Filter to student devices. The same controller relationship applies, and the school is responsible for any parental notice or consent required before deploying it. We practice strict data minimization there too: the filter records only blocked-site attempts (never general browsing), defaults to aggregate counts, and is governed by the Content Filter Addendum.
Questions about our privacy practices? Email us at privacy@thoushaltnotclick.com
“Every person's data deserves the same care and respect we owe every person.”
That's not just our policy — it's our promise.