An application’s name, logo and download count are easy to recognise. They are much weaker answers to a more important question: is this still the application your organisation intended to trust?
A reported Chrome impersonation on Google Play illustrates the gap between a convincing listing and a sound approval decision.
From Ball Bounce to a Chrome lookalike
In a report published on 15 October 2026, Bitdefender described an app that first appeared as Ball Bounce in August and was renamed Chrome in late September. It reportedly retained the package identifier com.ballbounce.Hizbartech.
A screenshot showed the listing in a sponsored position above the genuine browser, with more than 100,000 downloads. Users reported receiving an unrelated chat app. The listing was subsequently removed.
Those details need care. The download total may include installations from the app’s earlier life, so it is not a count of people deceived by the Chrome branding. Malicious behaviour was not independently confirmed. The case supports a discussion about impersonation and changing app identity without labelling the app proven malware.
Popularity does not establish identity
A familiar icon can help someone find an app quickly, but it cannot establish who built it or what the current version does. A sponsored position indicates advertising placement. A large install count reflects accumulated activity, which may relate to a different name or purpose.
That distinction matters during procurement, support calls and device enrolment. Instructions such as “search for the app with this logo” leave room for confusion. A managed distribution link to a specific approved application is more precise.
Give staff a route to obtain approved apps and a simple way to report a suspicious alternative. Security advice is easier to follow when the approved choice is easy to reach.
Record identity beyond the display name
For Android, Google explains that updates depend on package identity and a compatible signing identity, including supported key rotation, as well as version requirements. A package name alone is not proof of a trusted publisher.
For an approved app, record the package identifier, expected publisher and authorised distribution source. Where your tooling supports it, retain signing-certificate information and the accepted rotation history. Use the controls available in your device-management platform to distribute and restrict the intended application.
Even that is a starting point. Signing continuity helps establish a relationship between releases; it does not prove that a new release is appropriate for your organisation. Review changed permissions, data handling and business purpose as well.
Approval needs a change process
Store records can carry history across significant changes. Google’s developer guidance says app transfers preserve users, download statistics, ratings and reviews. That is a general platform behaviour, not evidence that ownership changed in the reported Chrome case.
Build a review process around the changes that could invalidate your original decision:
- Purpose: is the app still doing the job for which it was approved?
- Identity: have the publisher, distribution source or signing details changed?
- Access: does an update request additional permissions or reach new services?
- Data handling: do policy changes introduce new recipients or uses of information?
- Ownership: who in your organisation reviews the change and decides whether approval continues?
Browser extensions deserve the same attention. Chrome’s enterprise guidance covers extension ownership and management, while managed-browser policies can restrict permitted extensions and permissions. Reassess an extension when its access or ownership changes rather than relying on an old approval record.
Give brand impersonation an operational owner
For organisations publishing their own apps, monitoring should continue after launch. Include app stores, lookalike listings, sideload sites and relevant app-install advertising in the scope of your brand-protection process.
Agree what the team should preserve when it finds a suspected copy: listing URL, publisher, package identifier, screenshots, timestamps and the route through which it was discovered. Establish who can validate the finding, submit a platform report and coordinate customer communications.
A takedown is one response. Understanding whether people installed the app, what access it obtained and whether another listing replaces it may require further investigation. Keep those questions distinct from what the initial listing alone proves.
Keep the evidence behind approval current
MobSTR helps teams assess application code, permissions and dependencies and rescan as app-store versions change. InterroPol adds privacy-policy analysis alongside technical evidence. Together, they support a more informed application review as the software your organisation uses evolves.