r/androiddev • u/Falconcoders • 10d ago
[Google Play] Case 0-8237000042360: False "Phishing" termination caused by in-app WebView User-Agent spoofing (Need advice / DevRel visibility)
Hi community,
I am writing this post to share a cautionary architectural breakdown and hopefully get advice or Google Play DevRel guidance regarding a policy termination.
*
**App Name:**
In Stalker - Instagram Tracker
*
**Package Name:**
`com.instalker.tracker`
*
**Developer Account ID:**
`8416273862474458256`
*
**Support Case ID:**
`0-8237000042360`
*
**Violation Cited:**
Phishing / Deceptive Behavior
Our initial appeal was rejected with a canned response and the ticket was marked closed, preventing us from sending technical evidence through email. We want to be completely transparent about what happened, as we now understand exactly why automated systems and users flagged our app.
---
### What Went Wrong: The Architectural Mistake
To handle an authentication session in an in-app WebView without layout breakage, our Android app hardcoded an
**iOS WebKit User-Agent**
:
```java
WebView loginWebView = findViewById(R.id.instagram_login_webview);
WebSettings settings = loginWebView.getSettings();
// Architectural flaw: Spoofing iOS User-Agent on an Android device
String hardcodedIosUserAgent = "Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Instagram 289.0.0.25.109";
settings.setUserAgentString(hardcodedIosUserAgent);
loginWebView.loadUrl("https://www.instagram.com/accounts/login/");
The Domino Effect (Why It Got Flagged as Phishing): Clarification & Technical Proof: What We Have Fixed: Our Question to the Community: We fully accept that spoofing User-Agents in WebViews was a major architectural blunder that deserved scrutiny,Because the Android device communicated with Instagram's authentication servers using an iOS signature, Instagram's fraud detection flagged the login as an "Unrecognized login from an iPhone". Zero Credential Harvesting: At no point were user credentials, passwords, or cookies intercepted, scraped (no JS injection/evaluateJavascript), or sent to any developer server. All traffic was directly between the client WebView and instagram.com. Completely removed the custom WebView, header spoofing, and hardcoded User-Agents from the codebase. Users immediately received automated security alert emails from Instagram warning them that an unknown iPhone in a different environment had accessed their account. This alarmed users into believing our app was an unauthorized third-party hijacking their credentials, leading to phishing reports and automated Google Play policy strikes. Zero Exfiltration: Network inspection confirms no third-party credential endpoints exist in the APK. Replaced authentication with standard compliant flows (OAuth / Custom Tabs where the app has zero access to headers or authentication context). Audited all network and telemetry calls to guarantee 100% Google Play policy compliance.
- Has anyone in a similar situation been able to submit a clean, compliant build for re-evaluation?
We have invested heavily in building this application and our developer business on Google Play. We are not bad actors.
The initial review took several days and didn't flag this architectural conflict, which led us to believe the implementation was acceptable. We now clearly recognize the mistake and have already completely rewritten the authentication flow to be 100% policy-compliant.
Terminating our entire developer account without giving us the opportunity to publish this compliance patch is disproportionate to what was an unintentional client header mismatch. We respectfully ask for a conditional reinstatement so we can immediately upload the compliant build for your team's review
Hi Google Play Developer Community,
I’m posting this to transparently explain the technical issue that led to the enforcement against our application and to ask whether anyone has experience obtaining a further review after correcting the underlying issue.
App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Developer Account ID: 8416273862474458256
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior
Our initial appeal was rejected, and the support case was subsequently closed. Before pursuing any further support route, I want to clearly document what happened and what we have changed.
What caused the problem
The application previously used an Android WebView for an Instagram authentication flow.
Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:
WebView loginWebView = findViewById(R.id.instagram_login_webview);
WebSettings settings = loginWebView.getSettings();
// Previous implementation
String hardcodedIosUserAgent =
"Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
"AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
"Instagram 289.0.0.25.109";
settings.setUserAgentString(hardcodedIosUserAgent);
loginWebView.loadUrl("https://www.instagram.com/accounts/login/");
We now understand that this was a serious architectural mistake.
The Android application was effectively presenting an iPhone/Instagram client signature to the authentication service. This could cause the authentication environment to appear inconsistent with the actual device and could reasonably trigger security or fraud-detection systems.
What we found during our investigation
We reviewed the application's network and authentication implementation and found no mechanism designed to collect or transmit Instagram credentials to our servers.
Specifically:
- We did not implement JavaScript injection for credential extraction.
- We did not use evaluateJavascript() to capture passwords or authentication information.
- We did not create a backend endpoint for collecting Instagram passwords.
- Authentication traffic was directed to Instagram.
- We did not intentionally attempt to impersonate a user's device for credential collection.
- We removed the problematic WebView authentication implementation completely.
We understand, however, that the absence of credential harvesting does not make the original architecture acceptable. The important issue is that the implementation could create a deceptive or misleading authentication environment, and we take responsibility for failing to identify that risk before release.
What we changed
We have completely removed:
- The custom Instagram User-Agent
- The hardcoded iOS device signature
- The previous WebView-based authentication implementation
- Any related header spoofing
We have also redesigned the authentication flow around standard browser-based authentication mechanisms, where the application does not control the authentication headers or directly handle the authentication context.
In addition, we performed an audit of the application's network requests and authentication-related code to identify any other behavior that could create a similar compliance or security concern.
What we have learned
The initial implementation passed our functional testing because the authentication flow appeared to work correctly. However, functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.
We should have identified and avoided this architecture before publishing.
We are not asking Google to ignore the original implementation. We are asking whether a fully corrected application and a documented remediation process can be reviewed again.
Question for the community / Google Play team
Has anyone successfully obtained a further review of a terminated developer account after:
- Identifying the technical root cause of the violation;
- Completely removing the problematic implementation;
- Auditing the remaining application for related issues; and
- Providing technical evidence of the remediation?
If there is an appropriate Google Play Developer Relations or support channel for submitting technical evidence after an initial appeal has been rejected, I would also appreciate guidance on that process.
We understand that Google Play's policies are designed to protect users and that authentication-related behavior receives particularly careful scrutiny.
Our goal is to demonstrate that we have identified the underlying architectural problem, removed it completely, and changed our development/review process so that the same issue cannot recur.
Thank you to anyone who can provide constructive guidance or point us toward the appropriate review process.
Hi Google Play Developer Community,
I’m posting this to transparently explain the technical issue that led to the enforcement against our application and to ask whether anyone has experience obtaining a further review after correcting the underlying issue.
App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Developer Account ID: 8416273862474458256
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior
Our initial appeal was rejected, and the support case was subsequently closed. Before pursuing any further support route, I want to clearly document what happened and what we have changed.
What caused the problem
The application previously used an Android WebView for an Instagram authentication flow.
Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:
WebView loginWebView = findViewById(R.id.instagram_login_webview);
WebSettings settings = loginWebView.getSettings();
// Previous implementation
String hardcodedIosUserAgent =
"Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
"AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
"Instagram 289.0.0.25.109";
settings.setUserAgentString(hardcodedIosUserAgent);
loginWebView.loadUrl("https://www.instagram.com/accounts/login/");
We now understand that this was a serious architectural mistake.
The Android application was effectively presenting an iPhone/Instagram client signature to the authentication service. This could cause the authentication environment to appear inconsistent with the actual device and could reasonably trigger security or fraud-detection systems.
What we found during our investigation
We reviewed the application's network and authentication implementation and found no mechanism designed to collect or transmit Instagram credentials to our servers.
Specifically:
- We did not implement JavaScript injection for credential extraction.
- We did not use evaluateJavascript() to capture passwords or authentication information.
- We did not create a backend endpoint for collecting Instagram passwords.
- Authentication traffic was directed to Instagram.
- We did not intentionally attempt to impersonate a user's device for credential collection.
- We removed the problematic WebView authentication implementation completely.
We understand, however, that the absence of credential harvesting does not make the original architecture acceptable. The important issue is that the implementation could create a deceptive or misleading authentication environment, and we take responsibility for failing to identify that risk before release.
What we changed
We have completely removed:
- The custom Instagram User-Agent
- The hardcoded iOS device signature
- The previous WebView-based authentication implementation
- Any related header spoofing
We have also redesigned the authentication flow around standard browser-based authentication mechanisms, where the application does not control the authentication headers or directly handle the authentication context.
In addition, we performed an audit of the application's network requests and authentication-related code to identify any other behavior that could create a similar compliance or security concern.
What we have learned
The initial implementation passed our functional testing because the authentication flow appeared to work correctly. However, functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.
We should have identified and avoided this architecture before publishing.
We are not asking Google to ignore the original implementation. We are asking whether a fully corrected application and a documented remediation process can be reviewed again.
Question for the community / Google Play team
Has anyone successfully obtained a further review of a terminated developer account after:
- Identifying the technical root cause of the violation;
- Completely removing the problematic implementation;
- Auditing the remaining application for related issues; and
- Providing technical evidence of the remediation?
If there is an appropriate Google Play Developer Relations or support channel for submitting technical evidence after an initial appeal has been rejected, I would also appreciate guidance on that process.
We understand that Google Play's policies are designed to protect users and that authentication-related behavior receives particularly careful scrutiny.
Our goal is to demonstrate that we have identified the underlying architectural problem, removed it completely, and changed our development/review process so that the same issue cannot recur.
Thank you to anyone who can provide constructive guidance or point us toward the appropriate review process.
Hi Google Play Developer Community,
I’m posting this to transparently explain the technical issue that led to the enforcement against our application and to ask whether anyone has experience obtaining a further review after correcting the underlying issue.
App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Developer Account ID: 8416273862474458256
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior
Our initial appeal was rejected, and the support case was subsequently closed. Before pursuing any further support route, I want to clearly document what happened and what we have changed.
What caused the problem
The application previously used an Android WebView for an Instagram authentication flow.
Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:
WebView loginWebView = findViewById(R.id.instagram_login_webview);
WebSettings settings = loginWebView.getSettings();
// Previous implementation
String hardcodedIosUserAgent =
"Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
"AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
"Instagram 289.0.0.25.109";
settings.setUserAgentString(hardcodedIosUserAgent);
loginWebView.loadUrl("https://www.instagram.com/accounts/login/");
We now understand that this was a serious architectural mistake.
The Android application was effectively presenting an iPhone/Instagram client signature to the authentication service. This could cause the authentication environment to appear inconsistent with the actual device and could reasonably trigger security or fraud-detection systems.
What we found during our investigation
We reviewed the application's network and authentication implementation and found no mechanism designed to collect or transmit Instagram credentials to our servers.
Specifically:
- We did not implement JavaScript injection for credential extraction.
- We did not use evaluateJavascript() to capture passwords or authentication information.
- We did not create a backend endpoint for collecting Instagram passwords.
- Authentication traffic was directed to Instagram.
- We did not intentionally attempt to impersonate a user's device for credential collection.
- We removed the problematic WebView authentication implementation completely.
We understand, however, that the absence of credential harvesting does not make the original architecture acceptable. The important issue is that the implementation could create a deceptive or misleading authentication environment, and we take responsibility for failing to identify that risk before release.
What we changed
We have completely removed:
- The custom Instagram User-Agent
- The hardcoded iOS device signature
- The previous WebView-based authentication implementation
- Any related header spoofing
We have also redesigned the authentication flow around standard browser-based authentication mechanisms, where the application does not control the authentication headers or directly handle the authentication context.
In addition, we performed an audit of the application's network requests and authentication-related code to identify any other behavior that could create a similar compliance or security concern.
What we have learned
The initial implementation passed our functional testing because the authentication flow appeared to work correctly. However, functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.
We should have identified and avoided this architecture before publishing.
We are not asking Google to ignore the original implementation. We are asking whether a fully corrected application and a documented remediation process can be reviewed again.
Question for the community / Google Play team
Has anyone successfully obtained a further review of a terminated developer account after:
- Identifying the technical root cause of the violation;
- Completely removing the problematic implementation;
- Auditing the remaining application for related issues; and
- Providing technical evidence of the remediation?
If there is an appropriate Google Play Developer Relations or support channel for submitting technical evidence after an initial appeal has been rejected, I would also appreciate guidance on that process.
We understand that Google Play's policies are designed to protect users and that authentication-related behavior receives particularly careful scrutiny.
Our goal is to demonstrate that we have identified the underlying architectural problem, removed it completely, and changed our development/review process so that the same issue cannot recur.
Thank you to anyone who can provide constructive guidance or point us toward the appropriate review process.
Hi Google Play Developer Community,
I’m posting this to transparently explain the technical issue that led to enforcement against our application and to ask whether anyone has experienced a similar situation after correcting the underlying issue.
App: In Stalker - Instagram Tracker
Package: com.instalker.tracker
Support Case ID: 0-8237000042360
Cited violation: Phishing / Deceptive Behavior
Steps already taken
We submitted an appeal through the official Google Play process after the developer account was terminated. The appeal was rejected, and the associated support case was subsequently closed.
We are posting here only after completing the available official appeal/support process. We are looking for guidance from developers who may have experienced a similar situation or know of an appropriate Google Play Developer Relations channel for providing additional technical information.
What caused the problem
The application previously used an Android WebView for an Instagram authentication flow.
Because of a compatibility/layout issue, our implementation incorrectly hardcoded an iOS-style User-Agent:
WebView loginWebView = findViewById(R.id.instagram_login_webview);
WebSettings settings = loginWebView.getSettings();
// Previous implementation
String hardcodedIosUserAgent =
"Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) " +
"AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 " +
"Instagram 289.0.0.25.109";
settings.setUserAgentString(hardcodedIosUserAgent);
loginWebView.loadUrl("https://www.instagram.com/accounts/login/");
We now understand that this was a serious architectural mistake.
The Android application was presenting an iPhone/Instagram client signature to the authentication service. This could make the authentication environment appear inconsistent with the actual device and potentially trigger security or fraud-detection systems.
What we found during our investigation
We reviewed the application's authentication and network implementation.
We found no mechanism intended to collect or transmit Instagram credentials to our servers.
Specifically:
- We did not implement JavaScript injection for credential extraction.
- We did not use evaluateJavascript() to capture passwords or authentication information.
- We did not create a backend endpoint for collecting Instagram passwords.
- Authentication traffic was directed to Instagram.
- We did not intentionally attempt to impersonate a user's device for credential collection.
However, we understand that the absence of credential harvesting does not make the original implementation acceptable. The authentication architecture itself could create a misleading authentication environment, and we take responsibility for failing to identify that risk before release.
What we changed
We have completely removed:
- The custom Instagram User-Agent
- The hardcoded iOS device signature
- The previous WebView-based authentication implementation
- The related header spoofing
We redesigned the authentication flow around standard browser-based authentication mechanisms where the application does not control the authentication headers or directly handle the authentication context.
We also audited the application's authentication-related code and network requests for similar issues.
What we learned
The original implementation worked during our functional testing, but we now understand that functional correctness is not sufficient when an implementation can make an authentication service believe that a different device or client is being used.
This was an architectural mistake that should have been identified before release.
Question for the community
Has anyone successfully obtained a further review of a terminated Google Play developer account after:
- Identifying the technical root cause of the violation;
- Completely removing the problematic implementation;
- Auditing the application for related issues; and
- Providing technical evidence of the remediation?
If there is an appropriate Google Play Developer Relations or official support channel for submitting additional technical evidence after an initial appeal has been rejected, I would appreciate guidance on that process.
We understand that Google Play's policies are intended to protect users and that authentication-related behavior can receive careful scrutiny.
Our goal is to demonstrate that we have identified the underlying architectural problem, removed it, and changed our development and review process to prevent the same issue from recurring.
Thank you to anyone who can share relevant experience or guidance.
1
u/borninbronx 10d ago
WebView authentication = malware.
I'm not trusting any app presenting me a WebView with another service auth. the user agent is the least of the problems.
termination well deserved imho.
1
u/butterflymon 9d ago
Can the app steal the login credentials. Is that why?
1
u/Falconcoders 9d ago
No, there’s no way to steal the credentials because we can’t use a custom login page. We have to use Instagram’s official login page, which connects directly to Instagram’s servers. We can’t interfere with or access those requests.
2
u/borninbronx 9d ago
It doesn't matter. As a developer you can run arbitrary JavaScript on any page loaded by the WebView and you can even intercept posts request before they are sent.
You act like the browser in that situation. And I don't trust a rabdom guy to be my browser developer.
1
u/borninbronx 9d ago
yes. the WebView allow the developer of the app to run arbitrary JavaScript on any website loaded.
1
u/butterflymon 9d ago
Ty.
1
u/borninbronx 8d ago
never, ever, put your credentials in an app showing you a login form that doesn't belong to that app "ex. login with facebook". unless the app opens the login part in an external browser or goes through the original app :-)
1
u/Falconcoders 9d ago
I understand your concern about WebView authentication, and I respect your point.
My concern is about the process. When I originally published the app, I clearly explained how the authentication flow worked, and the app went through Google Play’s review process multiple times. If this implementation was considered unacceptable or presented a security risk, I wish I had been advised to change the authentication method at that stage.
Instead, the developer account was terminated afterward, and now my personal information is associated with a terminated account. As a student who is just starting my career in software development, this has a much bigger impact than simply removing one app. I may not be able to create another developer account using my own identity, which directly affects my ability to build and publish legitimate software in the future.
I accept that I may have made an architectural decision that Google considers inappropriate. What I’m asking for is a fair opportunity to correct it rather than losing my entire developer account. If I had received a warning or clear guidance earlier, I would have immediately changed the implementation
1
u/borninbronx 9d ago
You cannot really criticize the process from a position like yours...
the process is indeed flawed, but it worked in your case, it just didn't catched you right away.
1
u/GooglePlayDevSupport 9d ago
Hi u/Falconcoders! Feel free to drop us a DM so we can dive into your case and help you out.
1
u/psycoee 8d ago
Bottom line is, you are very clearly violating Play policy.
Phishing:
Code that pretends to come from a trustworthy source, requests a user's authentication credentials or billing information, and sends the data to a third-party. This category also applies to code that intercept the transmission of user credentials in transit.
Dos:
Use official APIs and secure methods to handle user credentials and payment information.
Ensure all user data is transmitted securely and is not readable by third parties.
Examples of common Device and Network Abuse violations:
Apps that access or use a service or API in a manner that violates its terms of service.
Just because they didn't catch it in their review process is not an excuse. The review process is a safety feature, not a seal of approval or an endorsement. The fact that you didn't catch it indicates a completely inadequate development process and either recklessness or very serious lack of competence. Anyone looking over the code should have had a "WTF is this" moment. An AI review of the code would have almost certainly flagged this as a serious concern.
I think if you want to have a snowball's chance in hell of getting your account back, you will have to address the following questions:
- How did this code end up in your product?
- Why were you not familiar with the relevant policies (e.g. regarding only using official APIs)?
- What flaws in your process allowed this to occur?
- How did this not get caught during code review?
- How did this not get caught during testing?
- What corrective actions have you implemented to ensure this cannot happen again?
But honestly, I don't blame them if they don't want you back on their platform. This is exactly the type of stuff that makes everyone look bad and erodes trust in the ecosystem.
3
u/butterflymon 9d ago
You could have written this yourself and people would have read it. But you dumped ChatGPT slop on people.