Cursorly is exactly what it claims::119-147 injects a <style> rule setting `cursor:url(blob:…)` from a pack the user picked,:1-2 loads seven catalog adapters that GET public cursor listings into IndexedDB (), and renders that grid. There is no POST, sendBeacon, eval, Function, chrome.cookies, webRequest or executeScript anywhere in the 14 JS files (greps returned empty), so no user data of any kind leaves the browser and the ML score plus the chrome-stats score are both manifest-level opinions that the code contradicts; chrome-stats also reports the extension as removed-for-policy_violation while the supplied context says Status: active, so those two signals disagree with each other. Mandatory manifest cross-check: the bundle is MV3 with permissions ['storage'] + host_permissions ['*://*/*'], while the published summary is MV2 with ['storage','tabs','*://*/*','notifications'] — the bundle is a strict subset and the split indicates the live listing summary describes an older build than this 2.0.1 ZIP, i.e. the opposite direction from a delayed-malicious update. Hygiene only, not findings::191-222 exposes `set` (arbitrary chrome.storage.local write) and `getConfig` (full local-storage read) over onMessageExternal to the publisher's own first-party [domain withheld], but the match pattern `*://*.[domain withheld] also permits plain http, and the stored keys are only, so the worst remote write swaps the cursor image URL;:259-261 and open [domain withheld] on update and custom-cursor.world on uninstall, which is affiliate-style promotion rather than a security issue.