Permissions and privacy
The analysis runs inside your browser. Not one request goes to turksem.com. Nothing about the pages you look at is collected or transmitted, and exactly one value is ever written to disk: the theme you picked yourself.
The four permissions
| Permission | What it is for |
|---|---|
| activeTab | Access to one tab, the one whose icon you clicked, from the moment of the click. Reading the page, and asking that site's own server for robots.txt, llms.txt and the page headers, all come from here. It survives a route change, a hash change, a same-site navigation, a reload and you switching tabs. It falls away when the tab goes to another site, and it does not come back. |
| scripting | Putting the reader into the clicked tab, at the click and again when a navigation tears it out. There are no static content scripts, so nothing of this extension ever runs on a page by itself. |
| storage | Writing the tab to read and the probe cache into session storage, which lives in memory and is wiped when the browser closes. Local storage holds exactly one thing: your theme choice. |
| sidePanel | Opening the panel. |
There is no permission covering all sites, no access to your browsing history, no request interception and no hidden background page. Without the opt-in below, the extension reaches exactly one tab: the one whose icon you clicked.
The optional one, granted by nobody until you press a button
The manifest carries one optional entry, and it works as a fence rather than as a permission. It says what the panel's own opt-in button may ask for: one site at a time, and only from your own press. Nothing is granted until you press it, and the same control takes it back.
What that line adds at install time was measured rather than assumed. Run against the manifest with and without it, the browser's own function for install warnings returns an empty list both times. The details page at chrome://extensions comes out identical too: it still says the extension requires no special permissions and has no additional site access, until you grant a site yourself.
What leaves your browser
Four requests, and all four go to the analyzed page's own server:
- /robots.txt on that site, sent without cookies.
- /llms.txt on that site, sent without cookies.
- A HEAD request on the page address, to read its response headers.
- A GET request on the page address, to fetch the HTML the server sent before any JavaScript ran.
That is the whole of it. Nothing goes to turksem.com, no measuring service is called, and no usage data is sent anywhere. Every request carries a ten second limit and asks for a fresh copy rather than a cached one. The link to the deeper analysis on turksem.com is a plain link: nothing is requested until you click it, and then it is your click.
Why the requests leave from a worker
This part is worth reading, because it is the difference between a claim that is nearly true and one that is exact.
A response header can tell the document that made the request to go and fetch something else. The browser reads the header, decides the document will want that resource, and downloads it. So while the panel made its own four requests, the analyzed site could name any third-party address in a header and the panel would obediently go and get it. That is not a theory. A test page put such a header on every answer and a listening server logged the hits, and this repository's own development server did the same by accident, pulling eleven files into the panel.
So the four requests moved out of the panel and into a worker. The whole point is that a worker has no document, so a header like that has nothing to act on. Measured in the same panel before and after: eight requests before, zero after. The build now fails if a fetch reappears anywhere that has a document, because otherwise the regression would be one innocent line with nothing wrong on screen.
What is stored, and for how long
| Where | What | How long |
|---|---|---|
| Session storage, in memory | The tab to read, and the probe results per site. | Ten minutes for the probe cache; everything goes when the browser closes. A failed request never enters the cache, so a momentary outage cannot keep lying for ten minutes. |
| Local storage, on disk | Your theme choice: Auto, Light or Dark. | Until you change it. A preference that dies with the browser is not a preference at all. |
| Nowhere | Page content, addresses, analysis results, scores, findings. | They live in the open panel and go when it goes. The source HTML is not even cached in memory: it is single use and runs to megabytes. |
Two more things it does not do
- The share card image is not downloaded. Its address sits in the preview as text, because fetching an image from a remote server would break the sentence above.
- There is no account and no sign-in, so there is nothing that could link a page you looked at to a person. No usage is reported anywhere, in any form.
The one address it opens by itself
Right after the install, the browser opens the product page in your browser's language. That address is baked into the package, and it is the only one the extension ever opens without you asking.