360 Filter

AI Security Review

Evidence context: threat category none; evidence quality moderate.

360 Filter bills itself as a content filter for computers managed by 360 Kiosk and 360shmira, and this build's code matches that label. All eleven findings are the same species: outbound fetch calls recorded at named lines. Seven sit in src/sw/service-worker.js, at lines 144, 157, 318, 641 and 750 among others. Four more are in src/offscreen/classifier.js at lines 44, 45, 115 and 234, with single calls at src/sw/image-analyzer.js line 33 and src/pages/pdfview.js line 259. That is the whole finding set. No malware signatures, no IoCs, no obfuscation, no secrets, no dependency problems, no manifest issues, and not one code-smell rule fired.

The shape of those calls fits the stated job. A service worker that fetches, an image analyzer that fetches, an offscreen classifier that fetches and a PDF viewer that fetches is what a filtering extension looks like internally, because something has to inspect the page, the image or the document and decide whether it belongs on a kiosk. Version 0.9.2 is an early build, and the description says outright that the extension does nothing unless an administrator enables it, which is how managed-deployment filters behave.

The strongest argument against this reading is that the evidence stops short of naming destinations. The findings record that a fetch happens at those lines, not where it goes, and the declared permission and host permission lists come back empty. An empty permission list on an extension that clearly makes requests points to a parsing gap on our side rather than to code reaching the network with no permissions at all. The request URLs inside src/sw/service-worker.js are the place to look to close that gap, and they would settle the question in minutes.

Attribution is thin. The developer is listed as [email protected], which carries no company name, and the install count shows zero. A Gmail address is not evidence of anything by itself, and 360shmira is an existing content-filtering service aimed at managed machines, so the deployment target named in the description reads as plausible rather than invented.

Weigh what is actually present. Eleven fetch call sites spread across a classifier, an image analyzer, a PDF viewer and a service worker, with zero corroborating signals of harm: no suspicious domain, no scrambled payload, no credential access, no malware family match, no data-exfiltration primitive in any file. The scanner's network rule flags fetch call sites on sight, and a content filter exists to make fetches. A build whose only flagged behavior is the fetching its own description requires, with nothing else firing across any other detection category, is best explained by the rule's breadth rather than by the extension.

Key Reasons

• All 11 findings are NET-FETCH call sites in a content filter's service worker, classifier, image analyzer and PDF viewer (src/sw/service-worker.js, src/offscreen/classifier.js)
• Zero IoC, malware-signature, obfuscation, secret, dependency, manifest-analysis or code-smell findings in the build
• Behavior matches the stated purpose of a managed content filter that only runs when an administrator enables it
• No suspicious domain, credential access or exfiltration primitive appears in any scanned file
• Fetch destinations are unresolved and the declared permission list is empty, which is the main open gap

False Positive Considerations

• NET-FETCH network rule flags every fetch call site regardless of destination
• Content classification for pages, images and PDFs requires outbound requests by design
• No corroborating malware, IoC, obfuscation or code-smell findings anywhere in the build
• Empty permission and host permission lists indicate manifest parsing gaps rather than hidden capability

Reviewed 2026-10-15; recommended action: no action; model confidence 72%.