উক্তি

How Ukti works inside

For anyone deciding whether to trust Ukti, or curious how it is built. All the code is open on GitHub.

The parts

Ukti is a Manifest V3 Chrome extension:

  • Content script: runs on each page. It draws the floating control and puts text into boxes. The control lives in a shadow root, so no site’s CSS can reach it and it reaches nothing of the site’s.
  • Offscreen document: a hidden page where the microphone opens, speech is recognised through the Web Speech API (language bn-BD or bn-IN), and translation runs through Chrome’s Translator API.
  • Service worker: routes messages between the two.
  • Banglish engine: pronunciation rules, a dictionary, and a list of about 450,000 Bangla words shipped inside the extension as a 704 KB Bloom filter.

Permissions

Two only: storage (settings and the word list) and offscreen (the hidden page). No host_permissions.

Chrome’s install dialog still says “Read and change all your data on all websites”. That comes from the content script’s matches, which cover every http and https page, not from a permission; measured with Chrome’s own getPermissionWarningsByManifest. activeTab would avoid it, but then the control would no longer appear by itself when you click into a box: you would press the toolbar icon on each tab first. That would lose the whole point of the product.

Network

Ukti’s own code makes no network request. Two things back that up:

  • On Ukti’s own pages (popup, setup, the words page, the offscreen document), the manifest’s content security policy has connect-src 'none', so Chrome itself refuses any request. A test makes one on purpose and sees it refused.
  • The content script runs under each site’s own policy, so there the guarantee is the code: a test searches every code file for fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon, importScripts and remote src.

What does go over the network is Chrome’s doing: Web Speech audio to Google, and downloading the language packs.

The hard part: putting text into a box

Users never see this, but it is where most of Ukti’s work is.

Every modern editor accepts text its own way. Gemini’s composer is built on Quill: it lets a synthetic paste land in the page, then a moment later rewrites the page from its own internal model and the pasted text is gone. WhatsApp’s is built on Lexical, which is the opposite: it honours the paste and nothing else. So “try one way and check at once” gives the wrong answer in both.

Ukti tries three ways in turn: paste, execCommand, and a direct Range. After each, it gives the editor time to finish its own work, then checks what the box actually holds. Before writing anything, it makes sure the whole box really is selected; otherwise a paste would land at the cursor and the sentence would end up in the box twice. If no way works, it puts the original text back exactly and says that it could not.

That is why Ukti works in places where other tools fail, and where it cannot, it does not damage your text.

Password and payment fields

type="password", the autocomplete values one-time-code and cc-*, fields masked with CSS, and PIN or card widgets built with contenteditable are excluded, and the check is repeated at the moment of use. A password field built as a plain text box with no sign of what it is cannot be recognised; that is a limitation.

Security

So that a web page cannot switch the microphone on by itself, Ukti obeys only the user’s real clicks and key presses, not events made by script. Only the active tab can start listening. The microphone stops when the page navigates away, the tab closes or the frame is removed.

What has not been verified

The automated tests run in the cloud and cannot reach gemini.google.com or web.whatsapp.com, so they run against pages built to behave like those editors. Testing on the real sites happens on the author’s own computer. Dictation into Gemini is still an open problem.