Privacy
Last updated 5 August 2026
Sift filters the listings on a page from a sentence you type, so it has to look at the page you are on. This says exactly what leaves your browser, when, and why — in the same words the code uses.
The short version
Two things leave your browser, and only when you run a filter:
- The structure of the page — only the first time Sift sees that layout.
- The text of the listings being judged — only for the parts of your request that can't be decided with a number or an exact value.
Nothing leaves your browser before you accept the notice inside the extension, and nothing leaves it from pages where you never pressed run.
What is sent, precisely
1. A structure sample — only on a cache miss
When Sift hasn't seen a page's layout before, it sends a structure-only sample: element tags, class names, ARIA and data attributes, and up to the first 80 characters of text per node, capped at about 40 KB. That is what lets it work out which repeating block is the result list and which text is the price. The result is a schema — selectors and field names, no listing content — cached against a hash of the layout, so the next visit sends nothing.
2. Listing text — only for judgement
Numeric and exact-value tests (price < 400,
year >= 2010, fuel = diesel) are evaluated inside
your browser and never transmitted. Only when a criterion needs judgement —
“family car”, “thriller”, “junior friendly” — are the candidate listings sent:
the fields your request names, plus up to 600 characters of the card's visible
text. Listings that already failed a local test are not sent at all.
3. Item pages you asked for
If a criterion needs an attribute that only exists on a listing's own page, Sift fetches that page from your browser, with your session, and extracts the named fields. Only the extracted fields are used; the page itself is not uploaded.
4. Account and usage data
Your email address for sign-in, your credit balance and ledger, and per run: the site host, the query text, and counts of listings seen and matched.
What is never sent
- Cookies, tokens, or any credential.
- Form values you have typed into the page.
localStorage,sessionStorageor IndexedDB contents from the site.- Pages on which you did not run a filter.
- Anything at all before you accept the in-product notice.
- Anything from a host you have not granted permission for.
Who processes it
Sift's own backend at sift.koglabs.com, and from there the model
provider selected for that task. On the bring-your-own-key plan the requests
go to your provider account with your key; that key is encrypted at rest with
AES-256-GCM and is never returned by any endpoint, including to you.
Retention
| Listing text sent for judgement | Not persisted after the run; the in-flight cache is swept every 6 hours |
|---|---|
| Page structure samples | Not persisted — only the derived schema is stored |
| Derived schemas | Cached per host and layout hash, with no listing content |
| Runs | Host, query, counts and credits, until you delete your account |
| Credit ledger | For the life of the account — it is the billing record |
| Sessions | 30 days, or until you sign out |
Your controls
- Consent — the first run asks. Decline and nothing is uploaded.
- Per-site permission — Chrome asks before Sift can touch a new site.
- Restore — one click returns any page to what the site rendered.
- Delete — deleting your account removes your sessions, saved filters, runs and ledger with it.
- Bring your own key — if you'd rather no third party saw your traffic under our account.
Permissions, and why each one exists
activeTab | To read and filter the page you are looking at, when you press run |
|---|---|
optional_host_permissions | Requested per site, on your action — never at install |
scripting | To inject the filtering code into that page |
storage | Session token, saved filters and the schema cache, locally |
sidePanel | The panel the extension runs in |
The extension requests no host permissions at install time.
Security posture
The extension holds no API key and makes no model call — there is no provider
client in its bundle, and its content security policy allows connections to
sift.koglabs.com only. All model traffic is proxied by the
backend. The credit ledger is written server-side, transactionally; the
balance shown in the UI is a cache and is never trusted as input.