NoaLingua Documentation
Every permission, why it exists, and what it cannot do
NoaLingua asks for four narrow permissions at install, plus the hosts its dictionary files come from, plus content scripts that match every site — which is what produces Chrome’s broad-access warning. Permission to fetch a document is separate, and is deferred until you first press a PDF button.
Requested at install
| Permission | What it is for | What it cannot do |
|---|---|---|
| storage | Keeps settings, saved vocabulary and the review schedule on your machine. | Grants no network access and no access to page content. |
| alarms | Lets download retries and review reminders survive Chrome suspending the background worker, which it does constantly. | Reads nothing. It only schedules the extension to wake itself. |
| notifications | The optional “you have words ready to review” reminder, off by default. | Carries no data anywhere; the count comes from your own local queue. |
| contextMenus | Adds “Translate with NoaLingua” and “Open as bilingual book” to the right-click menu. | Sees nothing until you choose the item on a selection you made. |
The broad-access warning, and where it comes from
Chrome will say the extension can read and change your data on all websites. That is accurate, and it comes from content scripts rather than from host permissions — a distinction Chrome does not draw for you.
Two scripts match every site. One registers a text-selection listener, so the word card can open on any page. The other checks whether the page has a video element with a readable caption track, which is the only way any site beyond YouTube and Netflix works at all.
What they do not do: read the page before you act, send page content anywhere, or keep running on a page that has neither a selection nor a captioned video. Both can be switched off in Settings, and the generic video adapter has its own toggle separate from YouTube and Netflix.
Host access, and why it is narrow
The extension declares tatoeba.org, download.wikdict.com, kaikki.org and huggingface.co, plus two of Hugging Face’s CDN hosts for large-file redirects. All of them exist for one purpose — downloading static dictionary, grammar, example and punctuation data.
Each of those services sends no CORS header, which is exactly why a host permission is needed: without one, a background fetch cannot read them at all.
These are file downloads. Nothing about you is transmitted with them, and none of them can read a page you are on.
Why <all_urls> is optional and requested late
Reading a PDF needs broad URL access, and requesting that at install produces the alarming permission warning that teaches people to distrust extensions.
An extension page runs on its own origin, so fetching an ordinary https://…/file.pdf is a cross-origin request — and almost no document server sends the header that would permit it. Chrome therefore has to ask.
So the request is deferred until you actually press a PDF button. Until you do, the extension has exactly the access listed above, and the permission is only ever used to read the document you just asked for.
Calls that need no host permission
A reviewer, or anyone watching a network tab, will see requests that are not in the host list: the licence check, and the optional single-word grammar lookups.
These need no host permission because those endpoints send CORS headers, which is the ordinary way a browser permits a cross-origin request. It is not a loophole — it means the receiving server has explicitly allowed it.
What travels: for the licence check, a licence key. For grammar lookups, one word — never the sentence, never subtitle text.
The wider picture — what is stored, what can leave and under which setting — is set out on the local-first feature page and in the privacy policy.