For security teams · 15 minutes

Data handling

For each thing the PhishTriage browser extension does: what leaves the device, where it goes, and how long it is kept. Then the processors, what a team can see, deletion, and the administrator policy keys that change data flows.

Versions and scope

• Extension. The browser stores serve version 1.0.0. Behaviour below is that version’s unless a line says otherwise.
• Policy. Privacy policy version 1.10, effective 4 October 2026. Its header says it applies to the browser extension version 1.1.0 and later, and to the default backend services at api.phishtriage.com and — only with file protection switched on — filescan.phishtriage.com. A material change (a new collection, a new processor, a different retention period) bumps the version and the effective date. Earlier versions are available from privacy@phishtriage.com.
• Where the two differ. Where version 1.0.0 behaves differently from what policy 1.10 describes, this page describes version 1.0.0. The differences:
  • The feedback buttons send nothing; a press is kept on the device. Policy 1.10 describes a press being sent by default.
  • Outlook at outlook.cloud.microsoft is read as an ordinary web page, not as mail. There are four mail hosts, not the policy’s five, and the install permissions name only those four.
  • Nothing is captured on the mail hosts, whatever the verdict. Policy 1.10 describes 1.1.0, which there keeps a screenshot cropped to the analysed message and that message’s HTML after a phishing or suspicious verdict, never the inbox.
  • The 1.0.0 builds in the stores differ from each other in page-text limits (5,000 or 10,000 characters), in whether frames are read, in whether the full-page warning’s text is stripped from a page check, and in whether the File protection switch is offered. Policy 1.10 describes the 10,000-character limit, frames, all of PhishTriage’s own panels stripped, and File protection on Chrome, Edge, Brave and Firefox.
• Controller. The PhishTriage team, for the hosted service. Where an organisation runs its own backend (self-hosting is offered with Enterprise, on request), that organisation is the controller for the backend’s records, and the policy describes only the extension’s behaviour.
• Hosted retention. Every period below is the hosted service’s. A self-hosted backend sets its own.

What runs before anyone presses anything

• Install permissions: activeTab, storage, scripting, and host access to four mail hosts — mail.google.com, outlook.office.com, outlook.office365.com and outlook.live.com — declared as static content-script matches. There is no identity permission: the extension cannot read the account the browser is signed in with.
• Optional permissions, requested only when the feature that needs them is switched on: webNavigation for monitoring, downloads for file protection, and <all_urls> for either. With neither on, no host access beyond the four mail hosts is requested.
• On the four mail hosts, the content script loads on every page at document_idle and watches the page’s structure continuously, so it can keep the Analyze button in place. It reads no message content and sends nothing until Analyze is pressed.
• With file protection on, script registrations are attached to <all_urls> at document_start in every frame — two (four files) on Chrome, Edge and Brave, fewer on Firefox — so a file a page builds can be examined before it reaches the user. With file protection off, none of it is registered.
• Registration runs automatically at install (see the inventory). It is not a sign-up.

Source: the policy’s permission list under “TL;DR”, and “When you click ‘Analyze’ (on-demand triage)”. The four mail hosts are version 1.0.0’s; policy 1.10 adds a fifth, outlook.cloud.microsoft, from 1.1.0.

Inventory, per action

Every request to the backend also carries the device’s IP address, as every HTTP request does. What happens to it is under IP addresses and the application log.

Details for each row follow. Analyze and visit requests also carry the device’s pseudoId and, once registered, its extensionId. Evidence uploads, the start of a portal sign-in, the popup’s account check and, with file protection on, the blocklist refresh and every file check and full scan sent to filescan.phishtriage.com carry the device’s credential instead.

Registration

Runs from the browser’s install event, and again before the first scan of a session if that attempt did not succeed. There is no register control in the popup. Before registration the pseudoId is a 12-character random hexadecimal string generated on the device with crypto.getRandomValues; registration replaces it with a 32-character (128-bit) random value minted by the server. Neither is derived from an email address, IP address, hardware ID, fingerprint or any other identifier. Registration fails silently and retries; an unregistered device still scans. The stored extension record holds the extensionId, pseudoId, browser identifier, an optional label, when the device registered, and when it was last active — a timestamp rewritten on every scan and every visit ping that is recorded. Policy: “Pseudonymous ID” and “What the backend stores, and for how long”.

Email check and page check

• Trigger. Analyze in the popup (Analyze Current Email or Analyze Current Page), in the sidebar, or in the toolbar of Gmail or Outlook on the web. On an ordinary page the tab is read through activeTab; on the four mail hosts through the content script already loaded there.
• Mail hosts. Mail mode exists only on the four hosts above. Webmail on any other host, including Outlook at outlook.cloud.microsoft, gets the ordinary page check.
• Page text. Scripts, styles and the PhishTriage sidebar are stripped. In the newest 1.0.0 builds the full-page warning is stripped too; in earlier builds, pressing Analyze while the warning is showing sends the warning’s text with the page. Text hidden with display:none, visibility:hidden or the hidden attribute is included. In the newest 1.0.0 builds the 10,000-character cap counts the page and any readable frames together; earlier builds read the page alone, capped at 5,000.
• Frames. In the newest 1.0.0 builds only: text and links inside frames are included where the browser lets the page read them. For a frame from another site, only a count of content-sized frames is sent, plus a true/false for a page that is a bare wrapper around a frame. Where a page has no title, a same-origin frame’s title is sent as the title — for a document viewer that is often a filename.
• The URL. Sent in full. If it carries a session token or a search query, those are sent as part of it.
• Not read. Attachment contents. Input fields: what is typed into a form is not in the payload (but see evidence capture).
• Before a model reads it. Prompt-injection markers are removed (and where a line begins like an instruction, the rest of that line); the invisible padding newsletters put after their preview line is collapsed; line breaks in single-line fields become spaces. In the copy the model reads (not the stored one), the message’s own copies of PhishTriage’s section headings are marked “(quoted)”. Nothing is removed on privacy grounds: no address, URL or name is stripped.
• Stored. Triage record: the request body as above, the verdict, pseudoId, extensionId, a hashed IP, a cache key, a timestamp, which model tier answered (with the reason a tier ahead of it failed, if one did), and the date it will be deleted (see Retention). The server log also records each scan that reaches a model, with the raw IP, and is not deleted automatically; see IP addresses and the application log.

Policy: “When you click ‘Analyze’ (on-demand triage)” and “What the backend stores, and for how long”.

Evidence capture

• Default. On unless switched off: popup, Settings, Keep evidence of phishing. Shown during setup. Administrators can set it either way with evidenceCapture.
• When. The screenshot and HTML are taken at the moment Analyze is pressed on a web page, before the verdict exists, and held in the extension’s memory only. They are sent only if the verdict is phishing or suspicious; on any other verdict both are discarded. Nothing is captured on chrome:// pages, the Chrome Web Store or other extensions’ pages.
• What. A JPEG of the visible part of the tab, and the page’s full HTML, unfiltered — not the text extract described above. A capture over 1 MiB compressed is dropped whole.
• The mail exclusion is four hostnames, not a rule about email. On mail.google.com, outlook.office.com, outlook.office365.com and outlook.live.com nothing is captured. On any other webmail host — Yahoo Mail, Proton Mail, Fastmail, Zoho Mail, Roundcube, a company’s own Outlook Web Access — a phishing or suspicious verdict uploads a screenshot of the inbox and the HTML of the page, including the open message. That includes Outlook at outlook.cloud.microsoft.
• Typed values. The screenshot shows anything typed that is still visible. The HTML usually does not contain typed values, but a page can write them back into its markup.
• Stored. Screenshot and HTML, a SHA-256 of each, the scan’s verdict and cache key, account and device ids, the time received, and the capture time the browser claimed.
• Retention. Phishing: 12 months. Suspicious: 30 days. A suspicious capture a reviewer confirms moves to 12 months. Rejected by a reviewer: deleted immediately. Deleted with the account. The scan-history period does not apply to evidence, and the scan-history sweep does not touch it.
• Handling. Stored HTML is never rendered in the portal; it is downloaded as an inert file and served as plain text. A screenshot that is not really an image is refused.

Policy: “Keeping evidence of phishing pages”. On the mail hosts, the lines above are how version 1.0.0, the version in the stores, behaves. Policy 1.10 describes the next version, 1.1.0, which there keeps a screenshot cropped to the analysed message and that message’s HTML, never the inbox.

Background protection and Send full URLs

• Switches. Background protection is domain tracking. Send full URLs, under Advanced, is URL tracking. Both off by default. Turning either on prompts for webNavigation and <all_urls>; declining leaves the switch off.
• Domain tracking sends the hostname to /visit with type domain on each navigation. The full URL is not sent. The optional cache (off by default) limits this to once per hour per domain.
• URL tracking sends the full URL, path and query string included, on each main-frame navigation, with type url.
• Response. A threat verdict. If the backend calls the page dangerous, the extension injects its content script into that page to show a full-page warning.
• History. webNavigation fires on future navigations only. The extension does not enumerate or read browser history.
• Stored. Visit record: the URL or hostname, type, pseudoId, extensionId, hashed IP, timestamp and the date it will be deleted (see Retention). Beyond a set number of checks from one device in an hour, a check is still answered but no record is written. The server log also records the URL or hostname of each recorded check, and is not deleted automatically; see IP addresses and the application log.
• Managed fleets. trackDomains and trackVisits force either switch on or off, and a forced value beats the popup. Forcing one on does not grant webNavigation or access to all sites; without webNavigation nothing is sent.

Policy: “When you opt into URL or Domain Visit Tracking”.

File protection

• Where. Switched on under Settings, where the build shows the File protection switch; or by policy (fileProtection). Turning it on asks for downloads and access to all sites together.
• On the device. A file a page builds (blob: or data:) is read in the browser’s memory and checked there; the bytes are discarded straight after. An ordinary download is fetched a second time from its own address to be read, with the user’s cookies for that site, so a file behind a login can be read. That request carries no header, identifier or parameter of ours. A single-use link may fail the second fetch; the check then falls back to the file’s name and type.
• Sent for every download: the SHA-256 fingerprint, filename, size, the extension’s verdict, and the short reasons behind it. Most reasons are fixed phrases; some quote the file’s own name or extension; one quotes the name of an executable found inside a downloaded archive. The fingerprint is checked against known-malware fingerprints.
• Not sent to be looked up: the download’s address. It is checked on the device, against a threat list the extension refreshes from our backend at most once an hour when a download makes it look.
• The file itself is sent only for Check it properly (offered when a check is inconclusive; that one file) or with Deep scan every file on (every download; off by default; can be required by policy with deepScanAlways). It is scanned in memory on our own hardware and not stored; only the file-check record below is kept.
• Stored. Every check that reaches filescan.phishtriage.com, the default fingerprint check included, leaves a file-check record: the fingerprint, the file name (up to 300 characters), size, verdict, which check gave it, the deep scan’s engine or the malware signature it matched when there was one, pseudoId, extensionId, the time, and the date it will be deleted (see Retention). The person’s own dashboard does not show it; in a team, owners see it in the Team page’s Scans list, except in aggregate mode.
• File scanner log. One line per request: the request, its status, duration and the first eight characters of the extensionId; for a file check also the verdict, which check gave it, whether a deep scan was offered, a matched malware signature, and the first 60 characters of the file name. Not the IP address and not the file. Nothing deletes it automatically; see IP addresses and the application log.
• Not done. Files already on disk are not read, the Downloads folder is not watched, and an ordinary download cannot be stopped before it saves; for those the extension warns after the file lands and offers to delete it.

Policy: “When you opt into File protection (early access)” and “Third-party processors”.

Feedback buttons

In version 1.0.0 a press of Looks safe to me or Looks dangerous sends nothing. The sidebar shows “Thanks — saved on this device.” The answer is kept in the extension’s local storage: up to 100 entries, each with the verdict, which button was pressed, the time, whether it was an email or a web page, and the full address of the page or mail message it was pressed on. Sign out and Leave team do not clear these entries; removing the extension, or clearing its storage, does. Policy 1.10, written for 1.1.0 and later, describes a press being sent by default; see its “Your corrections to a verdict”.

Portal sign-in

• Flow. The popup’s Log in opens the portal; the person signs in with Google on Google’s pages. We never see a password.
• Stored. Account: an opaque account id, display name, roles, status, organisation and join time. Identity: issuer, the issuer’s subject id, the email address, whether the issuer says it is verified, the Google Workspace domain if any, first and last login times. Session, device and refresh tokens are stored hashed. No automatic expiry.
• The extension is told the account id and display name, and shows “Signed in as” that name. It is not given the email address. Every device signed in to one account carries that account’s id, so their requests are linked server-side.
• Without sign-in no identity record exists — except that an organisation owner who invites someone types their address into the invitation, and it is stored from then on, accepted or not.
• Google on every portal page. Each page loads Google’s sign-in library from accounts.google.com and fonts from fonts.googleapis.com and fonts.gstatic.com, before sign-in and whether or not anyone signs in. That tells Google the visitor’s IP address, browser, and that they were on the portal. No scan data goes to Google.

Policy: “Account and identity records”, “Pseudonymous ID” and “Third-party processors”.

Where analysis happens

Anything that needs a model is offered to backends in a fixed order. The first to return a usable answer is the one that answers:

1. a model PhishTriage hosts itself, on a machine it runs on its own network;
2. a third-party model service (Ollama Cloud) — configured in no deployment as of the effective date;
3. Anthropic’s Claude API, the last resort.

A tier is asked only if it is configured, not switched off, and the request has time left. A tier that fails — unreachable, too slow, an error, a rate limit, unparseable or wrongly shaped output — hands the same content to the next. The policy deliberately makes no promise that content stays on PhishTriage hardware, and gives no proportion: the fallback is a rule, not a ratio. In the week of 17 August 2026 a misconfiguration sent every scan to Anthropic.

For some emails a second request is made to the tier that just answered, with the same content and an added instruction. It never goes onward and never to Anthropic. The stored triage record notes which tier answered. The policy does not say where the model server is.

Policy: “Where analysis happens”.

Processors and destinations

The extension’s data goes to destinations PhishTriage operates:

• api.phishtriage.com — analysis, visit checks, evidence and accounts;
• filescan.phishtriage.com — only with file protection on;
• an internal intelligence hub, reached by the backend and never by the browser. Every flow to it is off in the shipped configuration and on the hosted service; see the policy’s “Shared threat intelligence”.

Records are stored in a PostgreSQL database on hardware PhishTriage owns and operates, in Estonia. No third-party storage provider has kept these records since production moved to PostgreSQL in August 2026. The processors the policy names:

• Anthropic — the Claude API, last tier of the order above. A processor under its API terms, under which inputs are not used to train models.
• Ollama — Ollama Cloud, the middle tier. Named before use; configured in no deployment as of the effective date.
• Cloudflare, Inc. — carries traffic between the browser and our server (TLS termination, tunnelling, DDoS protection). Data in transit only; it does not store records.
• Stripe — payments, and only if someone starts a checkout for a plan. It receives the signed-in email address at checkout and holds the card; we store an opaque reference and never see a card number.
• Google — portal sign-in, and every portal page load, as above. The policy notes that sign-in itself is not a processor relationship. It also says we receive Google’s Cross-Account Protection notices, which is how a Google account that has been hijacked or disabled loses its portal session.
• Elastic Cloud — the previous datastore, which held records from before the August 2026 migration. The project was deleted on 2 October 2026 and no copy was kept. What Elastic retains of a deleted project is governed by its terms.

The product includes no analytics, advertising, telemetry SDKs, error-reporting services or fingerprinting libraries. With file protection on, the second fetch of an ordinary download goes to the download’s own host, as described above. Policy: “Third-party processors”.

IP addresses and the application log

• Database. Triage records keep a hash of the IP: the first 12 hex characters (48 bits) of an unsalted SHA-256. The IPv4 space is small enough to reverse it, so treat it as pseudonymised, not anonymised. Visit records also keep a hashed IP.
• Triage log line, for every scan that reaches a model: the raw IP address, time, email or page, pseudoId, a hashed sender address, subject length, verdict, confidence and risk score, the escalation flag, which tier answered and why one ahead failed, and duration. On a page scan the “sender” is the hostname and the “subject” the title, so next to the raw IP the line all but names the site. It carries no body, page text, subject, title or full URL. A cache hit logs only the cache key and the time.
• Visit log line: the time, the hashed IP, the type, the URL or hostname, whether a record was written, and duration. For a check that is not recorded (see Background protection above) only the time, the type, that it was not recorded, and duration: no IP hash and no URL or hostname.
• Capacity log lines, the first time in an hour that scans from one network address are refused because it has used its hourly share, or that the service reaches its hourly ceiling: the time, when the hour ends, the share or ceiling, and a hash of an address (the same unsalted 12-character hash; for IPv6, of the address’s block). For the ceiling, the hashed address that sent the most scans that hour, with how many.
• File scanner log (with file protection on): no IP address; see File protection above.
• Lifetime. Nothing in either application deletes these logs, and the retention sweep does not touch them. A deletion request to privacy@phishtriage.com naming an extensionId covers them, including lines that carry only the pseudoId or account id that extensionId belongs to, and we clear those lines by hand. A capacity line has no extensionId in it: it names a hashed address and nothing else about anyone.

Policy: “What the backend stores, and for how long” and “The application log”.

What stays on the device

• The identity: pseudoId, extensionId, organisation and device tokens. Sign out and Leave team clear these, then register a fresh identity at once.
• The feedback entries described above.
• With file protection on: the URL blocklist and when it was fetched.
• Names of risky downloads that could not be shown a warning at the time.
• With Background protection and its cache on: the hostnames visited in the last hour.
• Settings, in chrome.storage.sync: if sync is on, browser sync can copy them to the account the browser syncs with (a Google, Microsoft or Mozilla account, or Brave’s sync chain). They are switch positions, not content.

Deletion requests act on our servers and cannot reach the browser profile. Policy: “What the extension keeps on your own device”.

Retention summary

• Triage, visit and file-check records are each given a deletion date when they are written, from the period in force at that moment for the account they are written under:
  • Default: 365 days, for records written since 4 October 2026, the effective date of policy 1.10. Before that, 90 days.
  • A team’s period: an owner can choose 7 to 365 days, on the Team page under Scan history (see Set up PhishTriage for a team). It applies to every member of the team and to every device the team set up.
  • A person’s own period: anyone signed in to the portal can choose 7 to 365 days for their own records: Dashboard, Your data, How long we keep your scans, Keep my scans for. In a team, the team’s period or a shorter one, never a longer one; if the owner later sets a period shorter than the member’s, the team’s applies to the member’s new records. It covers scans from devices linked to the person’s account; devices the organisation set up follow the team’s period. Owners are not shown the period a member chooses.
  • Not retroactive: a change sets the deletion date of records written after it only. A shorter period does not delete older records early, and a longer one does not keep them longer. Scan and visit records written before 4 October 2026 keep 90 days. File-check records had no deletion date until every record was given one, shortly before policy 1.10 took effect: those made before then were given 365 days from when each was made, and those made between then and 4 October 2026 were given 90.
  • The sweep removes records past their date several times a day, so a record can outlast its date by a few hours.
  The application log that also records scans and visits is not swept (below).
• Reports from the feedback buttons: 90 days after receipt, whatever period applies to scans. Version 1.0.0 sends none.
• Changes to a period: each change is recorded with who made it, from what to what, and when, and for a person’s own period, the team’s period at that moment. No scan content. Neither the sweep nor Delete my scan history removes it.
• Evidence: 12 months for phishing (and for suspicious captures a reviewer confirms); 30 days for suspicious; deleted immediately if a reviewer rejects it; deleted with the account. Not on the scan-history period.
• Device records: no expiry.
• Account and identity records: no automatic expiry. The account record holds the person’s own period, if they chose one, and when; the organisation record holds the team’s.
• Application log: records each scan that reaches a model and each Background protection or Send full URLs check; not deleted automatically; a person’s lines are cleared by hand on request to privacy@phishtriage.com. The same goes for the file scanner’s log.
• Files sent in full are scanned in memory and not stored; only the file-check record is kept.
• Records a device made before it was linked to an account stay under the device’s earlier identity. They are not shown in the dashboard, not reachable by the delete action, and are deleted by the sweep on the date each was given when it was written.
• After a sign-out: once Sign out or Leave team has discarded a device’s identity, records made under it can no longer be reached from any device or account. The sweep deletes them on the date each was given.
• The one-hour triage cache considers only records younger than an hour.

Policy: “Retention” and “Keeping evidence of phishing pages”.

What the team can see

Teams are created in the portal (Create a team). Only owners can open the Team page; every member, owner or not, sees the dashboard and its lists. What both show depends on the team’s Reporting mode. Every team starts in Aggregate. This describes the live portal.

• Not retroactive. An owner switches with Turn on attributed reporting. Activity recorded before the switch is never shown per person. Switch to aggregate hides per-person detail again at once; turning attributed on again starts a new window, and the period in between is never shown per person.
• From the join, in both modes. The team’s lists and totals include a member’s scans only from the moment that member joined — for the owner who created the team, the moment it was created. Scans recorded before then are not shown to the team or counted for it, and while the person is in the team they no longer appear on that person’s own dashboard either. In aggregate mode every list on the dashboard, a person’s own scans included, shows “Not shown”.
• How people join a team. By accepting an invitation; through an enrolment token pushed to the device by policy; or automatically, when an organisation has proved it owns an email domain and someone signs in to the portal with a verified Google address on it. The automatic join has no invitation, prompt or notice at sign-in; the portal then shows which organisation, when, and which domain. An account already in an organisation is never moved. A domain can be proved by a DNS TXT record or by the Google Workspace tenant, so checking DNS does not rule it out.
• Deleting. No organisation role can delete a member’s history, or undo the member’s own deletion.

Sources: the portal’s Team page; the policy’s “Keeping evidence of phishing pages” and “Account and identity records”.

Deletion and access requests

• Self-service. Signed-in users: portal, Dashboard, Your data, Delete my scan history. It removes every triage, visit and file-check record, every report from the feedback buttons, and every evidence capture stored under the account — including captures whose scan record has expired — immediately and irreversibly, without waiting for their deletion dates. It reaches only that account’s records. It does not remove the device record or the record of changes to a retention period, and does not reach records a device made before it was linked.
• One capture. The Phishing Evidence list deletes a single screenshot and its page source. Inside a team that is an owner’s action, and only in attributed mode.
• By email. privacy@phishtriage.com with the pseudoId or extensionId, for access, deletion or objection — including the device record and application-log lines. The popup shows the first eight characters of the extensionId under Settings, Advanced, Device ID; send those with the browser and the rough install date. Each browser install that was never linked has its own pseudoId. Responses within 30 days.
• Not in the portal: there is no account-deletion button and no device-removal button. Both go through privacy@phishtriage.com.
• Withdrawing consent for monitoring. Switch off Background protection (and Send full URLs), or remove the webNavigation permission at chrome://extensions → PhishTriage → Details → Permissions (Chrome, Edge, Brave) or about:addons → PhishTriage → Permissions (Firefox). Removing webNavigation stops the visit checks at once but does not reset the switches. Removing only the access to all sites does not stop them: hostnames or addresses are still sent. On a managed fleet the setting is the administrator’s.
• Other rights: to object (by email) and to complain to a data protection authority in the EU or UK.

Policy: “Retention” and “Your rights”.

Administrator policy keys that change data flows

These keys exist in the managed-storage schema of version 1.0.0. A key that is set wins over the user’s switch. The popup marks each controlled switch with a Managed badge and disables it. When proxyUrl, trackDomains, trackVisits or cacheDomainVisits is set, Settings also shows the notice “Some settings are managed by your organization and can’t be changed here.” There is no key for the feedback buttons, because in this version they send nothing.

• proxyUrl — the backend that everything for api.phishtriage.com goes to. Must be https://; unset means the default. There is no user setting for it.
• filescanUrl — the file-scan service endpoint (https://). Used only by file protection.
• trackDomains — forces Background protection (hostname per navigation) on or off.
• trackVisits — forces Send full URLs on or off. Forced on, the full URL of every main-frame navigation goes to the backend.
• cacheDomainVisits — whether the one-hour domain cache is used.
• evidenceCapture — forces Keep evidence of phishing on or off. The user default is on.
• fileProtection — forces file protection on or off. Forcing it on does not grant the downloads permission or access to all sites; without them nothing is checked.
• fileBlocking — forces file protection’s block mode, which holds a file a page builds and asks before it saves, or its warn mode. The fingerprint is sent in either mode; a held file’s card can also offer Check it properly.
• deepScanAlways — sends every downloaded file for a full scan. Requires file protection.
• enrolmentToken — sent with registration to join the device to an organisation. No user email is collected. An invalid or expired token leaves the device unenrolled.

Where each browser takes these keys, how an enrolment key joins browsers to a team, and the permissions a forced switch still needs: Roll out PhishTriage by browser policy. Managed rollout is offered with Enterprise; we can set it up with you (contact us).