Imagine you're checking IDs at a bar. You don't run a background check — you just glance at whether the photo matches the face. If it's wildly off, you flag it. That's Name2Pkg: a bouncer for Android apps that checks whether the user-facing app name and the developer-assigned package name tell a consistent story. The committed claim is narrow but real: malicious apps tend to have weaker correspondence between their display names (what users see in the store) and their package names (the internal Java namespace like com.developer.appname). Benign apps exhibit predictable patterns — "WhatsApp Messenger" maps naturally to com.whatsapp. Malware that impersonates legitimate apps or hides behind generic names produces statistical anomalies in this mapping. Name2Pkg trains a character-level sequence-to-sequence model on benign-only data to learn the conditional likelihood P(packagename | appname), then uses length-normalized negative log-likelihood as an anomaly score. Apps whose package names are poorly predicted by their display names get flagged. The architecture is deliberately minimal: a character-level encoder-decoder (the paper doesn't specify transformer vs. RNN explicitly, but the seq2seq framing and character-level granularity suggest a lightweight recurrent or small attention model) trained exclusively on benign samples. This is a one-class classification setup — no malware labels needed for training, only a calibrated threshold set using benign validation data. The model checkpoint is 3.57 MiB and runs inference at 28.20 ms per sample on CPU. For context, full APK-level deep learning detectors often require extracting bytecode, API call graphs, or permission manifests — all of which involve decompiling the APK, a process orders of magnitude more expensive. On a dataset of 67,129 real-world apps, Name2Pkg achieves ROC-AUC of 0.982 and malware recall of 0.885 at a false-positive rate of 0.044. These numbers are strong for a signal that uses literally two strings as input. But the integrity question matters: the paper doesn't name the dataset source (AndroZoo? VirusTotal? Custom scrape?), doesn't compare against any existing lightweight screening baseline by name, and the one-class training means the threshold calibration is sensitive to the benign distribution's representativeness. The 4.4% FPR means roughly 1 in 23 clean apps gets flagged — acceptable for a pre-filter that hands off to heavier analysis, problematic if used standalone. The ladder context is tricky because Name2Pkg isn't really competing with full malware detectors — it's proposing a new screening tier. The closest comparison would be metadata-based heuristics (permission-based classifiers, manifest scanners), but the paper doesn't benchmark against these. It competes implicitly against the null hypothesis of random screening or simple string-matching rules. The 0.982 AUC validates the underlying signal exists, but without head-to-head comparison against other lightweight methods, we can't place it precisely on the ladder. The obvious next experiment is adversarial robustness testing: what happens when malware authors deliberately choose package names that are predictable from their spoofed app names? A malware developer impersonating "WhatsApp" who also uses com.whatsapp.messenger as the package name would sail through this filter. The paper doesn't address this, and the honest read is probably (a) — scope and venue constraints for a conference paper, not evasion of a bad result. The second missing experiment is integration testing: what's the end-to-end lift when Name2Pkg is used as a pre-filter for a full detector pipeline? If it catches 88.5% of malware but the full detector already catches 99%, the marginal value depends entirely on the compute savings in the triage stage. Name2Pkg is a clever observation wrapped in a clean implementation. It doesn't replace malware detection — it proposes that the mismatch between what an app calls itself and what it names its internals is a cheap, fast, surprisingly informative signal. The milestone to watch is whether this signal survives adversarial adaptation, because any screening heuristic that malware authors can trivially defeat has a short shelf life.
