The only genuine concern is a server-controlled HTML channel::41-66 fetches [domain withheld] and assigns the returned `html` string straight into `popupContainer.innerHTML` on the new tab, and:21-30 + 94-106 builds shortcut tiles (href, img src, title) from server-supplied via string-concatenated HTML, so the publisher can repoint the user's top-site clicks or render arbitrary at any time with no extension update. Contradicting the ML verdict: search goes through chrome.search.query (:169) to the user's own default provider with no hijack, no user data is sent anywhere (both fetches are bare GETs of static JSON), only opens an install tab and sets an UTM uninstall URL while its indexedDB wipe touches only the extension's own origin, contains no remote url()/@import, and the bundled manifest matches the published CWS manifest exactly. The ML regex hits are fully explained by this code (js_innerhtml 2 =:54,58; js_appendchild 7 =:250,251,258,259,260 +:60,88; html_href_javascript 1 = the inert javascript:void(0) at:48); the permhash cluster (search + one host) is a generic new-tab template, and the publisher-malicious figure and the internal note both trace to the same 2026-09-13 malext-feed import rather than independent corroboration. jquery-3.7.1., and are referenced by but absent from the bundle (~87 KB of total_js_size_bytes unaccounted for, consistent with stock minified jQuery) and therefore went unreviewed, which is why this is not cleared outright.