Every line of this extension's own code is a local cursor skinner: only seeds chrome.storage defaults and opens the publisher's own [domain withheld] page on,:61-74 rasterises a bundled.cur file via canvas.toDataURL() into storage, and:22-34 injects that data-URI into a <style> block — there is not a single fetch, XMLHttpRequest, eval, Function, atob, sendBeacon, cookie or navigator access in any file (grep over all returns zero hits), so there is no exfiltration channel at all, and the bundled manifest matches the published manifest exactly (storage only, MV3, cur/* web-accessible). The 90 KB of JS missing from the analysis bundle is jquery., which I extracted from the stored CRX and hashed: ff1523fb7389539c84c65aba19260648793bb4f5e29329d2ee8804bc37a3fe6e, bit-identical to the official jQuery 3.6.0 SRI digest, so the full 103 KB the ML model measured is accounted for and clean. The Unit42 IoC listing is the one signal against this, so I diffed the IoC-era build 1.01.02 against 1.01.03 in our own CRX store: the only substantive change is the landing URL moving from [domain withheld] to [domain withheld] plus whitespace reformatting — no ad injection, affiliate redirect or tracking existed in either build, so the listing looks like a bulk family-level PUP classification of cursor extensions rather than a code-level finding; publisher reputation ( malicious) and the chrome-stats impact corroborate, while the ML score and the 10%-flagged permhash cluster (194k storage-only members, essentially the base rate) are the only contradicting inputs.