Motorola is hijacking the Amazon app on its own phones to skim affiliate fees

What happened

On May 25, 9to5Google documented that recent Motorola phones — including the Edge and Razr lines running Motorola's build of Android 14 — are intercepting traffic from the Amazon Shopping app and rewriting product URLs to attach a Motorola-owned affiliate tag. The behavior was first surfaced by users on Reddit and confirmed across multiple devices. It is not an opt-in feature, not disclosed in setup, and not surfaced anywhere in the system settings UI.

The mechanism appears to be a preinstalled system package — variously identified in adb dumps as a "Smart Connect" or "Moto Secure" helper — that holds elevated privileges and can hook outbound intents and certain HTTP requests originating from third-party apps. When a user taps a product inside the Amazon app and shares or opens it externally, the link emerges with `tag=motorola-20` (or a similar Motorola affiliate identifier) appended. The hijack happens inside the device, not at the network layer, which means TLS provides no protection — the OEM owns the runtime, so it can edit the request before it ever leaves the process.

Motorola has not publicly responded as of this writing. Amazon's affiliate program terms explicitly prohibit "cookie stuffing" and the kind of unattributed tag injection at issue here, and Amazon has historically banned accounts and clawed back commissions for far less. Lenovo, Motorola's parent, has a prior track record on this exact class of problem: the 2015 Superfish incident, where Lenovo laptops shipped with a root certificate that allowed ad injection into HTTPS traffic, ended in an FTC settlement.

Why it matters

The interesting part is not the affiliate skim. A few cents per Amazon click times some millions of devices is not the kind of revenue line that survives a board meeting once the lawyers cost it out. The interesting part is the capability surface this exposes: a major OEM has, and is willing to use, the power to silently modify outbound network behavior of a first-party app on hundreds of millions of devices.

Most mobile threat models assume the app sandbox is the trust boundary. Your auth library checks the cert pin, your payment SDK verifies the response signature, your analytics SDK uses certificate transparency. None of that helps if the OEM's system process is rewriting your intent payloads or your `Uri.parse` results before they cross the IPC boundary. The Amazon app is a useful canary here precisely because it is one of the most heavily instrumented commerce apps on the planet — and it still took an external blogger and a Reddit thread to notice.

Compare the prior art. Superfish (2015) was a TLS interception attack via a shared private key. Samsung's "App Cloner" controversies were about data exfiltration. Xiaomi's MIUI ad-injection in 2020 was at the browser layer. This Motorola case is narrower but more sophisticated: a targeted, per-domain rewrite of another vendor's app traffic, designed to be invisible to the user and to the affected app's telemetry. It is, in effect, a sanctioned man-in-the-middle, scoped just narrowly enough to look like a product feature rather than malware.

Community reaction on Hacker News (298 points, 400+ comments at time of writing) has been notably non-partisan. The top comment thread is from an ex-Amazon affiliate manager pointing out that injected tags from unauthorized publishers are treated as fraud and reversed at month-end — meaning Motorola is likely earning nothing on this and will eat a chargeback, which makes the engineering decision even harder to explain. The second thread is from a Lenovo employee (unverified, throwaway account) suggesting this shipped via a regional carrier customization SDK and may not have had central security review. Whether that's true or face-saving, it points at the actual systemic risk: OEM Android builds contain dozens of vendor-specific helper services with broad permissions, shipped through opaque supply chains, with no meaningful disclosure to the user or to the app developers whose traffic they touch.

What this means for your stack

If you ship an Android app that handles money, auth, or anything resembling a redirect URL, treat the OEM layer as part of your threat model — not the platform. Practical steps:

First, log your own outbound URLs at the edge and compare to what your server actually receives. If you generate a deep link or a share URL client-side, hash it before emit and verify the hash server-side on the inbound request. Any drift between what your client emitted and what the world received is a signal worth alerting on. This is cheap and would have caught the Motorola behavior on day one.

Second, stop trusting `Intent.ACTION_SEND` and `Intent.ACTION_VIEW` payloads as immutable. If you hand a URL to the system for sharing or opening, assume it may be mutated. For anything security-sensitive — OAuth redirects, payment confirmations, magic links — sign the URL with a short-lived HMAC and validate server-side. Affiliate-tag injection is the benign version of this attack; the malicious version is a redirect_uri swap on an OAuth flow.

Third, if you run an affiliate or partner program of your own, add tag-provenance validation. Amazon will figure this out and unwind the commissions; if you're a smaller program without that infrastructure, you'll just pay out fraud. A simple check: does the tag's claimed source (a publisher site, a known app) match the actual `Referer` and the IP geo and the device fingerprint? Tags that appear only from Motorola devices, only on outbound shares from competitor apps, are statistically detectable.

Looking ahead

The Superfish playbook suggests how this ends: a quiet OTA that removes the behavior, a terse statement about "a third-party SDK," and no meaningful consequence beyond reputational. The longer-term consequence, though, is that the assumption "the OEM is part of the trusted computing base" is now a load-bearing fiction for any Android app dealing with value transfer, and the industry's response — better attestation, signed intents, or app-level network observability — has not been built yet. Until it is, your best defense is the boring one: log what you emit, verify what you receive, and assume the device is hostile even when the user isn't.