Category: adware

Kudos, a shopping extension powered by Wildfire, in its current version invites users to “auto-activate Boost”—at which point any click, even Dismiss, invokes an affiliate link.  This is a bad deal for merchants, who pay commissions for things users would have bought anyway.  Plus it violates rules from applicable affiliate networks, which only allow shopping extensions to invoke affiliate links when users actually click.   In a particularly brazen twist, this feature shipped for everyone—first, un-disablable; later, on-by-default—for more than eleven months, and Kudos only changed the setting to off-by-default when I and others caught competing shopping extension Phia with a similar violation.

Kudos’ current practice

(This section describes Kudos’ practice as of October 16, 2026, when I posted the first version of this article.)

When a user installs Kudos, a post-install screen invites a user to “Auto-activate boost.”

The user can also turn on “Auto-activate Boost” from the Kudos settings screen.  A mouseover bubble repeats text from the post-install screen.

 

In a representative test, with Auto-activate Boost turned on, I requested temu.com.  A Kudos window appeared, proposing that I “Activate extra earnings” or “Activate & close”.  I instead clicked “Dismiss”.  Kudos opened a new tab invoking Kudos’ affiliate link to Temu, and when that tab finished loading, Kudos closed it. Video.  I saw the same behavior when clicking elsewhere, for example on the “Exclusions Apply” link.

While my screenshots and video show Kudos practices on Chrome on a desktop PC, Kudos’ Safari Mobile extension has the same Auto-activate Boost setting.  On Safari Mobile, Kudos’ new tab opens invisibly to the user (versus flashing briefly in the tab bar on Chrome for desktop).  As I demonstrated for Phia in July, a user can reveal the invisible window by opening Safari’s tab-switcher with excellent timing—though normal users would have no reason to attempt that, not to mention get the timing just right.

Initially, on for everyone, with no off switch

Kudos first shipped an auto-click feature in version 4.211.5.  As of that version, a click substantially anywhere in Kudos’ popup triggered Kudos’ affiliate link. The clickable area included whitespace, links labeled “Exclusions apply” and “View list of exclusions and rates”, the minimize button (“_”) sometimes shown in the top-right corner, and even the pipe separator (“|”) sometimes shown as a separator between user interface elements in Kudos windows. To confirm and preseve this behavior, I installed Kudos 4.299.2.  I requested Temu, clicked whitespace, and got a Kudos affiliate link.  See Video — note version confirmation at 0:01, click at 0:15, and new tab visible from 0:15 to 0:18, then auto-close by Kudos.

In my testing, the only portion of the Kudos popup that did not invoke the affiliate link was the top-left icon and Kudos branding, which instead opened a new tab to joinkudos.com.

In addition to hands-on testing, I checked Kudos extension source code (shown below after pretty-printing to restore line breaks). Like most extensions, Kudos is minified, but its original name survives when tagged as a DisplayName (yellow).

ste=Uo(ate).withConfig({displayName:"ExtensionWrapper", ...

Then a separate procedure sets ste’s onClick handler to the function minified as A (blue):

ste,
{
onClick: A,
tabIndex: 0,
ref: (e) => u(e),
isExpanded: l, ...

Click-handler A passes execution to D5 (grey) which eventually passes execution through to a chrome.tabs.create() with active set to false and index set to 0 (red), yielding a non-focused new first tab.

const A = (0, sr.useCallback)(
  async (e) => {
    e.preventDefault();
    const n = await D5(t, r);          // t = merchant, r = page type
    await n?.activate(), 
    ...
n = await chrome.tabs.create({
  url: t,
  active: !1,
  index: 0,
});

The code to auto-close the affiliate tab is adjacent. When the affiliate tab completes loading (orange), Kudos closes it (pink):

chrome.tabs.onUpdated.addListener((t, r) => {
  "complete" === r.status &&
  t === n.id &&
  (chrome.tabs.remove(n.id), e(!0));

I spot-checked Kudos extensions from version 4.211.5 through and including 4.307.3.  I studied minified HTML and JavaScript to confirm that these are similar in relevant respects.

Later, turned on by default

From version 4.308 through version 4.520.0, Kudos pre-activated the Auto-activate Boost setting. In this period, the Boost settings screen (popup.js) got the value for the Auto-activate Boost setting from code that treated the setting as on by default

[u,d] = useState(e?.preferences?.disableAutoBoostActivation ?? null)
y = u ?? false
v = !y
...

createElement(Pfe, null, "Auto-activate Boost", ...), ... isOn: v, onChange: k

If the user never touched the setting, u would be null, which would make y false, so v (set to not y) would be true, and the Auto-activate Boost setting in the settings screen would be set to isOn=true.

Kudos’ auto-activate code followed much the same logic.  From container.js:

y && !0 !== t?.preferences?.disableAutoBoostActivation

Here, y denotes whether the merchant supports Kudos’ Boost benefits (unrelated to the variable y from the prior code snippet).  !0 is always true.  With true on the left, the !== operator evaluates to true when the right side is anything other than true.  If the right side is null, undefined, or false (such as for a user who left the Auto-activate setting at its default), the right side will not equal true, so the overall expression will evaluate to true and Kudos will proceed with the automatic click.

Timeline

July 29, 2025 (version 4.211.5): Kudos began forcing  clicks—making its entire popup (even the minimize button) invoke the affiliate link.

December 18, 2025 (version 4.308.0): Kudos gave the automatic clicks a user-facing name (“Auto-activate Boost”) and a user interface element pre-activated by default.  For a user who did not change the setting, behavior remained as in 4.211.5.  But users gained the ability to turn the automatic clicks off by request.

July 17, 2026 (version 4.527.2): Kudos reversed the default, turning Auto-activate Boost off unless a user turned it on.  That’s eight days after I revealed shopping extension Phia forcing clicks.  The best interpretation is that Kudos realized it was likely to get caught as I or others continued testing more shopping extensions.

October 16, 2026 (version 4.657.0): I posted the first version of this article, revealing Kudos’ 4.308 (Auto-activate Boost user interface, on-by-default) and 4.527 (Auto-activate Boost off-by-default).  The same day I posted, Kudos removed the Auto-activate Boost feature.

***

Rakuten policies require that an extension maker “notify us [Rakuten] in writing” about any “revision” of an extension.  I’d like to see evidence that Kudos and Wildfire actually did what this rule requires—a particularly important step for material revisions such as making the entire window (including whitespace and minimize button) a link, offering an automatic click setting, or turning on automatic clicks by default.

Contracts and policies on point

The prohibition on automatic clicks is a network rule, designed to increase the incrementality of affiliate traffic and protect merchants from undue expense.

Relevant contract provisions:

• CJ Publisher Service Agreement: “Software may not be used to force clicks [or] perform redirects without an affirmative click by a user”.
• Rakuten Affiliate Network Policies: “The DSA [downloadable software application] must not force clicks or ‘cookie stuff’. The DSA must not insert a cookie onto the user’s computer without the user knowingly taking an action. … The only way the Supplier cookie can be set is by a voluntary click from the user.” Leaving no doubt, Rakuten continues: “The offer may not automatically redirect to the advertiser website, even if the user has indicated that they ‘always’ want to receive rewards… It must be clicked on by the consumer before the offer can be redirected.”
• Awin Code of Conduct: “Publishers only initiate tracking via a tracking link used for click tracking if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.” (emphasis added in each quote)

Kudos might argue that users should be allowed to authorize automatic clicks.  But users cannot alter network rules because users are not the beneficiaries of those rules, and are not even privy to the contracts that establish those rules.  In any event, a click on a minimize button or on whitespace is not an “affirmative click” and certainly not a “knowing” “voluntar[y] and intentional[] interact[ion] with the Ad Media or Tracking link.”

Chrome Web Store policies are on point too.  Google requires “related user action … before the inclusion of each affiliate code, link, or cookie.” Google specifically criticizes invoking affiliate links “when no discount, cashback, or donation is provided.”  Kudos violates this policy by invoking an affiliate link when a user merely clicks whitespace or a minimize/close button.

Towards resolution

Wildfire and Kudos should disable automatic clicks, and explain how this feature shipped.  Who designed it?  Who approved the feature generally?  Who approved the decision to turn on Auto-activate Boost by default, and to turn that off in July 2026?  Did anyone tell the networks about any of this?

Networks should audit Kudos and Wildfire traffic since July 29, 2025, when the feature appeared.

Merchants should demand refunds for commissions paid on auto-activated clicks, along with the fees passed through to their networks.  If it’s not possible to determine which commissions came from automatic clicks, networks should make a reasonable estimate, erring on the side of returning more to merchants.

Wildfire and Kudos should also pay the costs merchants and networks incur to investigate and remediate.

My bottom line: Merchants paid commissions on sales Kudos claimed credit for, through clicks plainly outside governing contracts. Merchants and networks are entitled to learn how much money Kudos took from them, and to get it back.

 

Revisions to this article

I revised this article on October 26, 2026 to discuss my discovery of Kudos’ behavior from version 4.211.5 through 4.307.3, the period in which there was no user interface to disable Kudos’ automatic clicks.  I also reorganized the introduction and timeline sections to discuss the new findings, and I updated the start date in the Resolution section.

I chose to expand and rework this article, rather than publish new findings in a new article, so that this document provides all relevant information in a single page, which I judge to be most useful for future readers.

Wildfire makes a variety of white-label cashback browser extensions. Some of their extensions—including at least Acorns, KashKick, and Super.com — open messages inviting user to “reactivate” cashback after another affiliate has claimed credit, even though affiliate network rules require the extensions to stand down in those circumstances.

Here’s the sequence.  First, a user installs a Wildfire partner shopping extension.  When a user browses a merchant site, the extension pops open a window inviting the user to click and earn cashback.  Suppose the user later clicks an affiliate link from another publisher to the same merchant. Wildfire then pops open a “reactivate” window encouraging the user to click the Wildfire offer again—thereby replacing the other publisher’s attribution with Wildfire’s.

See also this WildFire Acorns video showing me browsing Zulily, receiving and clicking a Wildfire Acorns popup, then browsing Retailmenot, clicking back to Zulily, and receiving the Acorns “reactivate” popup.  All testing by me, on a test device, September 28, 2026 in my lab.

Network rules

Affiliate network rules disallow Wildfire’s “reactivate” window.  Consider the leading US affiliate networks

CJ’s Publisher Service Agreement prohibits software publishers from “usurp[ing] a Transaction that might otherwise result in a Payout to another Publisher.”  Wildfire’s reactivate window claims funds that “might otherwise” flow to another publisher.

Impact’s Stand-Down Policy requires publishers to “refrain from actions that could … interfere with existing publisher-referred traffic.”  Impact continues: “Upon detecting prior publisher attribution, software must suppress marketing prompts: Do not display pop-ups, banners, or notifications encouraging users to activate cashback or other affiliate offers.”  Wildfire’s reactivate window “encourag[es]” a user to activate cashback.

Rakuten’s Network Policies explain that “’Stand-down’ means the software may not activate or redirect the end user to the advertiser site with their Supplier Affiliate link for the duration of the browser session.”  Wildfire’s reactivate window is a form of extension “activat[ion]” prohibited by that sentence.

Wildfire’s role

Because Wildfire supplies the underlying technology for multiple white-label extensions, the same design can affect multiple publishers and merchants. My technical analysis, below, indicates that the stand-down/reactivation functionality resides in Wildfire’s shared code rather than being separately implemented by each white-label extension.

Implementation details

Reviewing Wildfire’s code within the Acorns extension, I found that the reactivate function has a featureFlag setting. From src/shared/config.js:

featureFlags: { lostAffiliationDetectionEnabled: true }

I also reviewed the Wildfire code that consumes this setting and decides how to proceed.  First, handleAffiliateStandDown.js watches web requests.  If a request’s query string contains a parameter from the LostAttribution list in _standDownPolicy, it sets potentialLossOfAttributionDetectedFromTab. Later, handleLostAttribution.js runs when the tab finishes loading.  It checks that cashback was already activated for that domain and that the URL differs from the original activation URL.  It then sends a LOST_ATTRIBUTION message to the tab, prompting the reactivate message as shown above.

The code indicates that the lost-attribution/reactivation feature resides in Wildfire’s shared code, rather than being separately implemented by the individual shopping extensions. That is consistent with remarks on Wildfire’s site (“white-label”).

Remediation

In the telemetry sent from the user’s device to Wildfire’s server, Wildfire tracks the fact that another affiliate’s link was clicked (“LOST_AFF” in yellow below), but also the specific other affiliate that was to be credited (usually visible in the merchant’s landing page, url= parameter, in green below — here RetailMeNot with Rakuten publisher ID OOTtr9mlaCk).

GET https://wild.link/_sales/offer-view?d=51138069&c=4782751
&sc=&tc=696f885f-40ef-4cc1-aacb-357784ef9a6b&session_id=
b41104b1-8a3a-4b2f-abb4-03941e3c255f&session_step=1
&url=https%3A%2F%2Fwww.zulily.com%2F%3Futm_source%3DAffiliate
%26utm_medium%3Daffiliate%26utm_content%3DRetailMeNot
%26ranMID%3D54167%26ranEAID%3DOOTtr9mlaCk%26ranSiteID%3D
OOTtr9mlaCk-CHIdllrXwa1nTnnT5TSbWw&view=LOST_AFF
&action=OFFER_VIEWED&app_version=11.11.1 HTTP/1.1

This data creates a path to return funds to the publishers who would have been paid had it not been for Wildfire’s reactivate messages.  Any payment Wildfire and its partners received in a LOST_AFF session could then be identified for review and, where appropriate, redirected or reimbursed to the affected affiliate (per the green url= parameter).

Full remediation would also require Wildfire paying networks’ costs of investigating the violation.

 

“Activate & Close” with less prominent “Dismiss”

(added October 2, 2026)

The second and third screenshots, above, show unusual text in the top-right corner of the Wildfire popups: “Activate & Close.”  But the top-right of a popup is where users reasonably expect an X button that closes the window and takes no other action.

By placing “Activate & Close” in the top-right, and treating a click there as supposed basis to invoke an affiliate link, Wildfire popups invoke affiliate links in circumstances where users are best understood not to have requested that Wildfire do so.

An astute user will find a “Dismiss” link in the bottom-center of the Wildfire windows.  But that’s not a normal place for a button to close a window.

Testing other Wildfire extensions, I also see Acorns and Kudos using the misleading “Activate & Close” (at top-right) and “Dismiss” (at bottom-center) on their principal mobile screens to present affiliate links (though Acorns does not do this in its reactivate message, first screenshot above).  Acorns screenshot below (from video at 0:01).

Google’s Chrome Web Store allows affiliate links only when there is a “direct and transparent user benefit.”  But Wildfire button labels and placement are not “transparent” when the close function is moved to bottom-center, and when the top-right link serves both to close Wildfire’s popup and to invoke an affiliate link.

Under affiliate marketing contracts, an affiliate link may only be invoked in specific circumstances.  (Rakuten: only when “the user knowingly tak[es] an action”; Awin: “if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.”) I wrote last month about Phia’s “auto_drop” feature forcing clicks when users visit a merchant’s shopping cart – a practice that no network allows.  But even before Phia began forcing clicks, Phia was also improperly invoking affiliate links in other ways too.  My article today shows two additional violations: 1) Invoking affiliate links when users merely close a Phia slider.  2) Auto-refreshing cookies periodically.

Affiliate link on-exit

On mobile devices, Phia’s shopping extension invoked its affiliate link when a user tapped the “X” to close a Phia slider and when a user merely tapped outside a Phia slider (i.e. tapped back to the merchant’s site).

Contracts do not authorize Phia to invoke its affiliate link (and claim affiliate commission) when the user dismisses Phia and returns to the merchant’s site. Tapping an X or tapping a merchant’s site – these are clearly not a user “knowingly taking an action” (as Rakuten requires, contemplating an “action” that is meaningfully connected to affiliate marketing).  Nor are tapping X or a merchant site “voluntarily and intentionally interact[ing] with” affiliate content (Awin) since the X button and merchant site are plainly not affiliate content.

This iOS test video shows the on-exit affiliate link.  Key steps:

0:06: Phia opens its “coupons found” slider.

0:10: Tab switcher shows no other tab is open.

0:12: Tap outside the Phia slider.  (Notice no animation showing a tap within the slider.)

0:14: Tab switcher shows a new second tab open, loading the same merchant through an affiliate link.

As usual, skill is required to interpret Phia’s code.  First, it’s minified, which removes variable names and function names.  Second, it’s React, declarative rather than procedural.  But here’s a key section, with // comments added by me.  Notice that Phia correctly logs the user’s action as a dismiss (yellow), yet nonetheless invokes the affiliate link to claim commission (red).

y = (0, o.useCallback)(e => {
	if (!e) {   // slider is closing
		const e = null !== f.progress && "complete" !== f.progress.phase;
		f.cancel(), t.__debug || Ae.gf || c(),   // invoke affiliate link and place cookie
		e || Obe.getState().flush(), Z_.trackUserActivity({
			action: tu.rc.DISMISS,   // truthfully log this as a dismiss
			module: A && !m ? tu.nV.MODULE_BRAND_OFFERS : tu.nV.MODULE_COUPON,
			pageType: tu.g6.CHECKOUT_WEBPAGE,
			actionId: crypto.randomUUID(),
			sessionId: ny.getState().sessionId,
			requestId: l.current ?? void 0
		}), A && !m && t.onBrandOffersDismissed()
	}
	t.onOpenChange(e)
}, [f, t, c, A, m]),

Notably, Phia performs on-exit clicks only on mobile devices.  A network or merchant testing only the Chrome extension – and assuming the Safari extension works the same way since it’s substantially the same code base – would not see this violation.  Green highlighting shows the code implementing the restriction to mobile devices: On Chrome, Ae.gf=1, causes the || (logical OR) to stop processing before the c() call that invokes an affiliate link and places a cookie.

Phia’s on-exit clicks interact with auto_drop forced clicks in a subtle way.  Consider the possibilities once Phia shows a slider, with on-exit clicks active but auto_drop off (either before i=auto_drop shipped, or after Phia turned it off):

1) The user could click a genuine affiliate link (a proper click under the governing contract).

2) The user could click X to dismiss the slider.

3) The user could click outside the slider.

4) The user could close the tab or browser, or power-off the device.

Once Phia activated its affiliate-link-on-exit code, only path 4 avoids an affiliate link.  Notably, the on-exit functionality turns paths 2 and 3 into affiliate clicks even without auto_drop.  With on-exit shipped as of November 11, 2025 (based on what I see in historic versions of Phia’s code), paradoxically auto_drop (shipped December 13, 2025) didn’t actually increase the number of affiliate clicks – not because automatic clicks aren’t harmful (they are!), not because they’re permitted by rules (they’re not!), but because Phia was already forcing so many clicks through its on-exit code.

Thus, to see the harm from Phia’s impermissible invocation of affiliate links, analysis should begin not with the December 2025 deployment of auto_drop, but with the November 2025 deployment of on-exit clicks.  That broadly matches the growth I’ve seen in multiple sources that track Phia’s rise.  (For example, affiliate merchants that work with Phia can see when its clicks and conversions grew.)  This timeline extends the duration of Phia misconduct beyond what I alleged last month – and is certainly not consistent with Phia’s claim of problems limited to a single recent version (“a recent release”, as Phia claimed to Bloomberg last month).

For a separate assessment of the scope of Phia’s misconduct, I obtained data from an online tracking service that observes shopping sessions and affiliate clicks.  Prior to November 2025, the tracking service observed that of Phia sessions that included a merchant’s shopping cart page, less than 10% included a user clicking an affiliate link.  But after Phia shipped the on-exit code, more than 50% of such sessions included an affiliate link click (or fake click tracked as a click by this tracking service).

Two remarks on the chart.  First, when Phia was caught forcing clicks in July 2026, discussion focused on auto_drop forced clicks.  But once Phia stopped auto_drop, on-exit logic noticed no click had occurred yet, so it functioned as it was designed and ran a click on exit.  The suspension of both auto_drop and on-exit is what drives the sharp drop at the right of the chart: With either system running, Phia achieved clickthrough (genuine clicks or fake clicks tracked as clicks by the tracking service) as high as 80%.  But with both features disabled, clickthroughs dropped below 10%, where they had been before these features launched.

Second, one might ask why Phia users don’t more often click its affiliate links (why the baseline clickthrough rate is below 10%).  The answer lies in both the quality of Phia’s coupons and the way Phia presents them.  See video at 0:11, where Phia calls the coupons “a bit iffy” (i.e. unlikely to work) and asks users to copy-and-paste each coupon into the merchant’s site (without the auto-apply feature that some shopping assistants offer).  After seeing this message a few times, most users stop investing time applying coupons.  Based on likely user reaction, both the number of steps and the typical benefit, sub-10% user interaction with the “coupons found” screen is entirely believable.

Automatic cookie refresh

If a user browses merchant x, then returns to x after a timeout, Phia automatically refreshes the cookie by reinvoking the affiliate link.  Key code snippets, again with // comments by me:

const t = Ae.gf ? A.desktop : A.mobile;   // different cookie refresh configurations for desktop versus mobile 
t?.passiveWhitelist?.some(e => window.location.href.includes(e))
  && K("passive_trigger");   // check whether current URL is on whitelist for cookie-refresh

The function K() checks the duration since the last time this merchant’s affiliate link was invoked:

if (a) {
  const t = (Date.now() - a.timestamp) / Jp.dp,   // elapsed time since last affiliate link 
    n = U.current,
    i = Ae.gf ? n.desktop : n.mobile,
    s = i?.chipTimeouts[a.networkId],
    o = i?.chipTimeouts.default;
  let l = s?.[e] ?? o?.[e];   // required time gap for this network
  if (r && (l = 0), void 0 === l) return void L(!1);
  if (0 !== l && t < l) return void L(!1);   // if time less than threshold, do not invoke affiliate link 
}

These automatic cookie refreshes violate the same network rules I described last month.  CJ Publisher Service Agreement: “Software may not be used to force clicks [or] perform redirects without an affirmative click by a user” (but there is no affirmative click when a cookie is refreshed).  Rakuten Affiliate Network Policies: A shopping plugin must provide “full and prominent disclosure each time the DSA is triggered” (emphasis added) (disallowing multiple affiliate links with only a single disclosure).  Awin Code of Conduct: “Publishers only initiate tracking via a tracking link used for click tracking if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.”  The contracts nowhere contemplate one click authorizing multiple link invocations and multiple cookie refreshes hours or even days later.  That’s not how “links” work – one link, clicked once, loads the specified URL once.

Phia’s cookie refreshes have a distinctive signature in timestamps.  Ordinarily Phia opens its slider when a user is at a shopping cart – usually some minutes into a user’s session at a given merchant.  (Consider the time required to browse products and select an item to buy.)  But cookie refreshes occur as soon as a user reaches a merchant’s site.  And that’s what tracking data shows.  Initially, Phia’s affiliate links were basically never associated with the user’s first page-view of a shopping session, because multiple page-views are needed to reach the shopping cart.  But after Phia pushed the cookie refresh code (October 7, 2025), as many as 12% of Phia’s affiliate links came in the first page of a shopping session.

Reflections

The historic versions of Phia’s plug-in reveal the company’s priorities — adding feature after feature to accelerate revenue.  Phia’s forced clicks and other improper clicks do not present as a one-off error, nor are the problems limited to any single version.  Instead, Phia was experimenting with multiple forms of improper clicks.  The continued adjustments and optimizations repeatedly expanded the scenarios in which Phia collected commissions, even when users didn’t click and even when network rules didn’t authorize payment.

Today’s Bloomberg article discusses remarkable admissions in Phia’s internal communications, including founder Phoebe Gates instructing staff in December 2025: “can u confirm auto pop for cookie drop is live on ALL sites w a coupon to confirm we are monetizing on all gmv.”  That telling remark confirms the duration of auto_drop, consistent with my article last month (and contrary to Phia’s remarks to Bloomberg last month that the problem was limited to a single recent release).  But imagine if merchants and networks could see all of Phia’s communications (not just the subset that someone happened to share with Bloomberg, and Bloomberg chose to publish).  I’d like to read the engineering specifications for each feature, discussion of alternatives, and further discussion of network rules.  I’d also like to read correspondence with merchants and networks – what Phia told them it was doing, which I’d like to compare with what the code says.

Meanwhile, several people contacted me about Phia misconduct they reported to networks – and what, if anything, networks did about it.  Clearly networks had trouble uncovering Phia’s violations, even when tipped off.  Shopping plugins can be tricky to test, and in some ways mobile extensions are more difficult than desktop.  If merchants are to remain confident in affiliate marketing, more must be done to improve compliance and deter violations.

I’ve recently been looking at multiple forms of misconduct by Phia, a fast-growing shopping plugin.  I’m troubled by what I found, and even more troubled by Phia’s misleading public statements about these practices.  Based on my hands-on testing, code review, and other investigative methods, Phia appears to be materially out of compliance with network and merchant agreements.  Networks, merchants, and rule-following affiliates should be concerned, and in my view, all three groups have strong claims against Phia.

Forced clicks

The basic bargain of affiliate marketing is simple: an affiliate earns a commission only if it presents an offer, the user clicks, and the user purchases.  Network rules make clear that shopping plugins, like all other affiliates, are only allowed to invoke affiliate links—setting the cookies and other tracking codes that claim commission—if a user actually clicks an affiliate link.

See the CJ Publisher Service Agreement: “Software may not be used to force clicks [or] perform redirects without an affirmative click by a user”.  Rakuten Affiliate Network Policies: “The DSA must not force clicks or ‘cookie stuff’. The DSA must not insert a cookie onto the user’s computer without the user knowingly taking an action.”  Awin Code of Conduct: “Publishers only initiate tracking via a tracking link used for click tracking if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.”

This is arguably the most fundamental rule of affiliate marketing.  Almost two decades ago, I caught Shawn Hogan and Brian Dunning invoking affiliate links, and thereby claiming commission, without users clicking.  I reported this to eBay, which told the FBI, leading to criminal charges for wire fraud, breach of contract, RICO, and more.  Both men ultimately served jail time.  Details.

Phia appears to be doing much the same thing.  Phia’s iOS app and Chrome plugin both include a setting called enable_coupon_auto_drop that, when active, automatically invokes affiliate links without user action, most often when a user is at a merchant’s shopping cart or check-out page.  See this iOS test video, showing the affiliate link invisibly loaded into a second tab.  (In the video, at 0:05, the tab switcher window screen is opened so viewers can see the second tab loading, but normal users would have no reason to do this.)

Notably, Phia activates the auto_drop setting via a “feature flag” that allows server-side control of which devices receive forced clicks (yellow).  In my testing, this feature is always turned off for Chrome users.  But if a user-agent header references iOS (green), the feature flag server replies in the affirmative (blue).  Change the user-agent to a different value, while keeping everything else the same, and the feature flag becomes false.

curl -X POST \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" \
  -H "STATSIG-API-KEY: client-..." \
  -H "STATSIG-SDK-TYPE: javascript-client" \
  -H "STATSIG-SDK-VERSION: 3.31.0" \
  -H "Content-Type: application/json" \
  -d '{"user":{"userID":"...","platform":"IOS_SAFARI_EXTENSION",
              "appVersion":"1.10.26","platformVersion":"1.10.26"},
       "hash":"djb2","statsigMetadata":{"sdkType":"javascript-client","sdkVersion":"3.31.0"}}' \
  'https://featureassets.org/v1/initialize?k=client-...&st=javascript-client&sv=3.31.0&...'

  → HTTP 200, hash_used: djb2
  → derived_fields.browserName = "Mobile Safari"
  → derived_fields.osName      = "iOS"

  → feature_gates["3845139938"]   // decodeable to "enable_coupon_auto_drop"
    {
      "name": "3845139938",
      "value": true,

Thus, a user who tests only on desktop would never see these forced clicks. In my experience, many affiliate fraud testers test desktop only. That explains why this wasn’t promptly noticed.

Phia first shipped this feature in version 1.9.33 of its app, published on December 13, 2025.  Nonetheless, Phia told Bloomberg “a recent release our codebase was causing misattributions from a subset of users.”  I disagree that the problem was limited to “a recent release” of Phia.  There have been numerous intervening releases, making it difficult to characterize this as a problem confined to a single recent release (as Phia’s “a release” claims).  The feature appears to have persisted for roughly seven months, including the 2025 holiday shopping season—a significant period with real economic consequences

In remarks to industry bloggers Kris and Sarah, Phia downplays the forced clicks as a “bug.”  That characterization is difficult to reconcile with the evidence.  Phia intentionally built and shipped a feature which they themselves call “auto_drop” and which does what it says.  In no context in affiliate marketing is it ever permitted to “auto drop” an affiliate link and automatically set affiliate cookies.  Deliberately building and deploying a feature called “auto_drop” that automatically sets affiliate tracking — this cannot be dismissed as a mere bug.  It’s intentional, and it violates both trust and contract.

Consequences of forced clicks

It’s well-known within affiliate marketing that many users don’t click on affiliate links.  Suppose the click-through rate, when users are asked or encouraged to click, is 20%.  A publisher that fakes clicks gets a 5x increase in monetizable traffic, with no change to cost, yielding a disproportionate increase in profit.

Merchants are the main victims of forced clicks, which compel merchants to pay affiliate commissions on traffic they should have gotten at no charge (thanks to their reputation or SEO) or no additional charge (having already paid for SEM or other marketing).  When I advised merchants about fraud detection and remediation, my standard recommendation was to require rule-breaking affiliates—especially those who forced clicks—to pay back every penny they had taken, plus the costs of investigation (lawyers, experts, and more).  Multiple recoveries reached seven figures.

Stand-down violations

A second set of affiliate network rules pertains to who gets the marketing commission when multiple affiliates were involved (or claimed to be involved).  Let’s be specific.  Suppose a user clicks a NYT Wirecutter link recommending (say) Polaroid.com.  But on a computer with Phia installed, there’s an obvious risk: After a user puts a new camera in her cart, Phia can pop open, present its affiliate link, and claim it should get the commission.  But NYT incurred real costs (journalist salaries, health insurance, and office space), while Phia’s costs are minimal.  Furthermore, NYT was the genuine cause of the purchase, the actual first step in the user’s decision-making.  From a merchant’s perspective, a substantive product recommendation from NYT is far more valuable than a last-minute shopping-plugin intervention.  If Polaroid doesn’t protect NYT’s interest, NYT—and other high-quality publishers like it—will instead review, test, and recommend products from sellers that give them reasonable confidence in getting paid.

Fortunately there’s no need to resort to some amorphous sense of fairness to protect publishers from shopping plugins taking credit at the last minute.  To the contrary, networks and merchants for years have embodied these ideas in governing contracts.  CJ: “non-interference with competing advertiser/ publisher referrals”.  Rakuten: “Software Publishers must recognize and Stand-down on publisher-driven traffic.”  Details in my January 2025 write-up about Honey at heading “The contracts that bind Honey.”

I found it surprisingly easy to uncover examples of Phia not standing down.  In my first test session, I clicked a Savings.com link to Polaroid, added an item to my cart, and immediately got a Phia offer that, when clicked, invoked Phia’s affiliate link.  Video.

A particularly surprising aspect of my Savings.com-Polaroid-Phia test scenario is that Phia not only tracked the link I had clicked (yellow), but also watched the redirect chain (green), and explicitly recognized that I had clicked an affiliate link (blue).  From Phia’s /events telemetry immediately after the Savings.com link:

POST https://p.phia.com/events HTTP/1.1
Host: p.phia.com
...
{"eventName":168,"eventProperties":{"finalUrl":"https://www.polaroid.com/en_us/film?irclickid=QsFVXMyFfxyZR9d1lV0pGwW6UkuQ%3A9QPPWguSM0&sharedid=&irpid=10851&utm_medium=affiliate&utm_source=Savings.com%20.&irgwc=1&afsrc=1","matchedUrl":"https://polaroid.pxf.io/c/10851/2112974/24813?subId1=809258334-46-678567891459&u=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Ffilm","network_id":"unknown","domain":"www.polaroid.com",
"chain":["https://www.savings.com/m/offer?offerid=14626284","https://polaroid.pxf.io/c/10851/2112974/24813?subId1=809258334-46-678567891459&u=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Ffilm","https://www.ojrq.net/p/?return=https%3A%2F%2Fpolaroid.pxf.io%2Fc%2F10851%2F2112974%2F24813%3FsubId1%3D809258334-46-678567891459%26u%3Dhttps%253A%252F%252Fwww.polaroid.com%252Fen_us%252Ffilm%26level%3D1&cid=24813&tpsync=yes&auth=5ab2153b89b0c662","https://polaroid.pxf.io/c/10851/2112974/24813?subId1=809258334-46-678567891459&u=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Ffilm&level=1&brwsr=c81dd3a8-7776-11f1-9f75-554d085a42bf&brwsrsig=X%3A5TVmU4gVwtT4JQk70%3AXxo2y6UQlY","https://www.polaroid.com/en_us/film?irclickid=QsFVXMyFfxyZR9d1lV0pGwW6UkuQ%3A9QPPWguSM0&sharedid=&irpid=10851&utm_medium=affiliate&utm_source=Savings.com%20.&irgwc=1&afsrc=1"],
"os":"WINDOWS","phiaId":"...","osVersion":"10","platformVersion":"1.10.26","timestamp":"2026-07-04T07:05:49.491Z","deviceType":"PC","platform":"CHROME_EXTENSION"}}

HTTP/1.1 202 Accepted
{"status":"success","message":"Event EVENT_TYPE_AFFILIATE_COOKIE_COMPETITOR_DETECTED queued successfully"}

Despite recognizing “competitor” savings.com having invoked an affiliate link and set an “affiliate cookie” (blue), Phia nonetheless set its shouldStandDown status to false (yellow):

GET https://api.phia.com/whitelist/validate?url=https%3A%2F%2Fwww.polaroid.com%2Fen_us%2Fcameras&phiaId=1474393b-f7e7-4c25-9bff-affcfcbf10e2 HTTP/1.1
Host: api.phia.com
…

HTTP/1.1 200 OK …

{"isWhitelistedPage":true,"isProductPage":false,"shouldFirePageView":true,"shouldShowTopOfPage":false,"numImagesToScrape":1,"topOfPage":{"shouldShow":false,"ctaMessage":""},"showExtensionOnStandDown":true,"standDown":{"shouldStandDown":false,"shouldTakeover":false,"affiliateType":0,"decisionTtlSec":0,"featureSurfaces":[{"feature":1,"canShowSurface":true},{"feature":2,"canShowSurface":true},{"feature":3,"canShowSurface":true},{"feature":4,"canShowSurface":true}],"cookieSources":[{"source":1,"canPlaceAffiliateCookie":true},{"source":2,"canPlaceAffiliateCookie":true},{"source":3,"canPlaceAffiliateCookie":true},{"source":4,"canPlaceAffiliateCookie":true},{"source":5,"canPlaceAffiliateCookie":true},{"source":6,"canPlaceAffiliateCookie":true},{"source":7,"canPlaceAffiliateCookie":true},{"source":8,"canPlaceAffiliateCookie":true},{"source":9,"canPlaceAffiliateCookie":true},{"source":10,"canPlaceAffiliateCookie":true},{"source":11,"canPlaceAffiliateCookie":true}]}}

Then Phia did not stand down, as the video shows.

Consequences of stand-down violations

Stand-down violations are the core of ongoing litigation against Honey and others.  The same concern applies to Phia: Every dollar Phia takes through stand-down violation is a dollar that would otherwise flow to another publisher.  No wonder publishers are furious.

Reflections

There’s more to be found in Phia’s codebase, and more to be found in hands-on testing.  But I’ll stop here, for now, as to the substance of Phia’s misconduct.

Phia’s statements to Bloomberg and industry bloggers Kris and Sarah raise additional concerns.  “Phia has been reviewed and verified as compliant across the affiliate networks we work with,” they told Kris and Sarah.  I’ve never seen a network offer any kind of certification of compliance — at most they can say they didn’t find problems, but they can’t know what they didn’t find.  At most, affiliate-network review can fail to detect violations; it cannot certify their absence, and failure to catch a violation does not mean no violation occurred. Did affiliate network staff test the right scenario in the right way?  Did they test on iOS, not just desktop?  Did they test stand-down scenarios?  How many staff, with what experience, tested for how long?

Meanwhile, just as Honey conceals its practices to prevent network staff from uncovering its misconduct, Phia’s violations sit behind servers that can condition behavior on a user’s shopping history, browsing history, IP address, device type, and more.  When I recently drafted a model COC, I disallowed that tactic, instead requiring that key shopping-plugin decisions be made within the browser extension without consulting a server, a rule designed to make behavior more predictable.  See proposed rule 9.3 paragraph 3.  It is particularly unconvincing for Phia to claim networks did not uncover violations when Phia’s architecture makes violations difficult to detect.

A related concern is that Phia often participates in affiliate marketing as a subaffiliate, rather than establishing relationships directly with merchants.  When Phia’s traffic is merged with other subaffiliates, patterns of misconduct—like traffic spikes, implausible conversion rates, and implausible timing—become more difficult for a merchant or even a network to uncover.  Hence my recommendation that shopping plugins operate only through direct merchant relationships—see my model COC, proposed rule 5.2.

So many recent problems in affiliate marketing generally, and in shopping plugins specifically!  Much remains to be done to restore integrity to affiliate marketing, ensure that rule-following publishers are paid for the value they create, and give merchants confidence that they are paying only for genuine incremental value.