Forced Clicks and Stand-Down Violations by Shopping Plugin Phia

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.

Google Android Tying Confirmed Unlawful — But What Penalty for False Statements?

In 2014, I was the first to reveal previously-unknown Google contracts that required Android phone manufacturers and carriers to preload key Google apps, make them prominent, and in some instances not install competing apps.  In 2018, the European Commission ruled this unlawful and imposed a €4.1 billion fine, and today the European Court of Justice upheld the finding and fine, and rejected the appeal.

The wheels of justice turn slowly.  A ten digit fine is large, yet small relative to the benefit Google obtained by making its apps dominant in their respective fields — and demolishing competitors (or discouraging potential competitors from even trying).  And justice delayed, by 12+ years since I first reported the problem, is in an important sense justice denied.

But there’s an even bigger problem lurking.  Prior to me revealing the MADA contracts that embodied Google’s anticompetitive rules, Google leaders repeatedly claimed no such rules exist.  Quoting from my 2014 article:

Andy Rubin, then Senior Vice President of Mobile at Google, in 2011 claimed that “[D]evice makers are free to modify Android to customize any range of features for Android devices.” He continued: “If someone wishes to market a device as Android-compatible or include Google applications on the device, we do require the device to conform with some basic compatibility requirements [hyperlink in the original]. (After all, it would not be realistic to expect Google applications—or any applications for that matter—to operate flawlessly across incompatible devices).” Rubin’s post does not explicitly indicate that the referenced “basic compatibility requirements” are the only requirements Google imposes, but that’s the natural interpretation. Reading Rubin’s remarks, particularly in light of his introduction that Android is “an open platform,” most readers would conclude that there are no significant restrictions on app installation or search defaults.

Google Chairman Eric Schmidt offered particularly far-reaching remarks on Google’s rules about mobile apps and search defaults. After a 2011 Senate hearing about competition in online search, Senator Kohl asked Schmidt (question 8.a):

Has Google demanded that smartphone manufacturers make Google the default search engine as a condition of using the Android operating system?

Schmidt responded:

Google does not demand that smartphone manufacturers make Google the default search engine as a condition of using the Android operating system. …

One of the greatest benefits of Android is that it fosters competition at every level of the mobile market—including among application developers. Google respects the freedom of manufacturers to choose which applications should be pre-loaded on Android devices. Google does not condition access to or use of Android on pre-installation of any Google applications or on making Google the default search engine. …

Manufacturers can choose to pre-install Google applications on Android devices, but they can also choose to pre-install competing search applications like Yahoo! and Microsoft’s Bing. Many Android devices have pre-installed the Microsoft Bing and Yahoo! search applications. No matter which applications come pre-installed, the user can easily download Yahoo!, Microsoft’s Bing, and Google applications for free from the Android Market.

Schmidt’s response to Lee (question 15.b), to Franken (question 7), and to Blumenthal (question 7) were similar and, in sections, verbatim identical.

Rubin left Google in 2014 due to allegations of sexual harassment (albeit with a $90 million exit package).  Eric Schmidt was CEO and executive chairman of Google from 2001 to 2015, then executive chairman and technical advisor of Google parent Alphabet through 2020.  Neither has a current relationship with Google.  But lies last forever.  And Schmidt’s false statements to Congress were under penalty of perjury.  Though the statute of limitations for perjury has run, representatives can still contact Schmidt, demand further testimony to explore his false statements, and publicly condemn his misconduct if they, like I, conclude it was perjury.

Air France Cancelling Passenger Tickets Without Basis

Four groups of passengers have contacted me to report that Air France KLM has cancelled their ticketed and confirmed travel — despite AF KLM receiving payment (in points or money) and sending emails saying tickets were valid.  In one instance the cancellation occurred after check-in.  In two instances the cancellation occurred on the day of travel.

I recently filed a formal DOT complaint about one of these problems.  For two more, I am in correspondence with Air France KLM attorneys, and I expect to file DOT complaints if attorney correspondence does not bring the matters to a satisfactory resolution.

By all indications airlines are using some form of automation — dare they call it AI? — to decide which tickets to cancel.  But any process can make mistakes, AI even more so.  Airlines should have processes in place to receive passenger protests, to right the error, and to pay the resulting damages when, as here, their systems get it wrong.  In shooting first and asking questions later, airlines are playing a dangerous game — cancel a ticket that was booked with a small number of points, and passengers might have to pay a huge amount of cash to rebook at the last minute, exposing an airline to large damages.  From everything I’ve seen, Air France KLM’s approach is not just wrong, but also imprudent.

Compare Virgin Atlantic’s remarks last year, as part of resolution of a different complaint in which I represented passengers — there committing to improve their tools, and offer a new process for customer complaints and appeals.  Air France could learn a lot from Virgin Atlantic’s approach.

American Airlines downgrade compensation complaint with Mike Borsetti

Complaint. Docket with public comment form.

Status: Briefing underway.

Summary: AA’s revised Conditions of Carriage and International Tariff claim that if AA downgrades a passenger (for example, from business class to coach), AA need only refund 40% of the front-cabin fare — even if the difference in market price is much higher.  We challenge this provision as improper, unfair, and deceptive.

Code of Conduct for Affiliate Marketing Software

The past year brought renewed interest (1, 2, 3) in whether client-side software is playing fair, versus claiming affiliate commissions not truly earned.  “Fair” is arguably subjective, but fortunately disputes are grounded by contracts between software makers, affiliate networks, and merchants.

These contracts date back more than two decades.  They’ve been updated periodically, and that’s important to close any ambiguity or perceived ambiguity.  This week James Little and I proposed a full rewrite, designed to eliminate all doubt about rules and expectations.  We’ve provided a comment system so anyone interested can suggest adjustments.

Code of Conduct for Affiliates Using Browser Extensions and Other Client Software

Honey Hiding from Testers – The Next Steps

Three weeks ago, MegaLag and I revealed Honey not just breaking affiliate network rules (by failing to stand down when network rules require), but affirmatively hiding from testers.  This is an explosive finding.  It’s one thing to break stand-down rules – most plugins have been caught with violations from time to time, and usually their developers shrug, claim it was inadvertent, and promise to improve.  I’ve long suspected many of these violations were intentional.  But with Honey, finally I could prove intentionality.

So far, reaction has been muted.  Last week Honey silently changed its configuration files to turn off the “selective stand-down” trickery.  That’s a kind of admission, but without engaging with the substance of what the company did. Honey’s subsequent statement to Hello Partner was equally incomplete – blaming prior management, despite Honey making recent updates to the ssd configuration file, meaning someone at Honey certainly knew this feature was in place.  Honey co-founder Ryan Hudson was quick to defend Honey from prior allegations, but has been strikingly silent on this subject.

Affiliate networks are starting to take action.  Impact suspended Honey from its marketplace – though for how long, they didn’t say.  Rakuten kicked Honey out of its network completely – meaning that Rakuten merchants can’t work with Honey even if they want to.  No doubt Rakuten was frustrated that Honey repeatedly tricked Rakuten’s testers.  In fact, the publisher class action lawsuit against Honey reported 17 citations to Rakuten documents about Honey stand-down violations – confirming both that Honey has been trying these tricks for years, and that Rakuten was on their trail.  (Alas, the substance was redacted, at least for now.)  Meanwhile, LinkShare – the affiliate network Rakuten acquired in 2005 to form Rakuten Advertising – was historically tough on shopping plugin misconduct.  (In 2004, I showed Ebates installing through security exploits.  LinkShare ejected Ebates for a time, then quietly readmitted them.)  LinkShare’s historic tough stance on shopping plugin misconduct should flow through to Rakuten.  Based on both its recent frustration and its  historic track record, I fully credit Rakuten’s stated reason for penalizing Honey.  But cynics alleged “hypocrisy” from a “direct competitor”, pointing out that Rakuten runs a competing shopping plugin that benefits from Honey’s expulsion.

Ultimately I doubt expelling Honey is a viable long-term solution.  More likely, Honey will somehow apologize and be readmitted.  (After all, that’s what LinkShare did with Ebates 21 years ago, though to be sure the situations are somewhat different, and arguably there’s stronger proof of intentionality in Honey’s recent violations, compared to what I could prove about Ebates in 2004.)  Fundamentally, networks’ core function is to connect merchants and publishers.  Their culture, staff, and fees are centered on this capability, and anything else is anathema to them.  Some merchants are bound to want Honey back – affiliate managers are remarkably forgiving.  Expulsion from the Rakuten network is, weirdly, too severe a penalty – reducing Rakuten’s own revenue, hence not credible and unlikely to last.

Yet Rakuten is absolutely right to say Honey’s approach was unacceptable.  More is needed both to prevent similar problems from recurring, and to emphasize the seriousness of Honey’s violations.  Let me offer three suggestions.

First, networks should revise their rules about shopping plugins.  The rules date back to 2002.  (Not a typo!)  Some new practices are arguably not covered by many networks’ rules, and gaps and ambiguities are increasingly apparent.  With James Little, Group Commercial Director at TopCashback, I’m working on proposed new rules.  (Update, April 7, 2026: Our proposed rules are posted.)  We address situations that we believe to be unclear under current rules.  And we add new requirements designed to ease testing.  We’re mindful of our own fallibility, so we suggest an orderly process for any member of the public to raise apparent ambiguities.  In addition, rules should be revisited periodically – no more waiting for disaster or scandal.

Second, shopping plugins — not just Honey — need to come clean about prior violations.  MegaLag, I, and others have been tracking other plugins with stand-down violations.  VPT has been testing shopping plugins at scale for years, and has hundreds of violations on file.  If a shopping plugin that knows it had “bugs” within (say) the last year, it should affirmatively contact all networks to report what went wrong and how and when the problem was fixed.  Only “bugs” timely reported in that way should be treated as good faith mistakes.  And any other shopping plugin that intentionally hid from testers – yes, we have more examples – should turn itself in too.  The penalty for being caught by networks, or by independent testers like us, should be a lot worse than the penalty for admitting what happened.  Whatever penalty Honey faced, as the first shopping plugin caught intentionally hiding from testers – competitors should expect the penalty for the second to be a lot worse.

Third, Honey should pay a fine to networks.  This fine should be substantial, calibrated to Honey’s ill-gotten gains – the incremental revenue Honey collected when it intentionally did not stand down.  In due course the publisher class action may also obtain benefits for publishers, but that’s a separate matter, highly uncertain, and no grounds to reduce a payment to networks right now.  Two key reasons for a fine: One, a fine is credible in a way that suspension and expulsion are not.  Two, networks can use the fine revenue to redouble their compliance efforts.  Hire a few extra FTE’s for hands-on testing.  Build a lab with undercover devices to defeat geofencing.  Pay bounties to outsiders who find violations.  All of this feels expensive in the abstract, but with a seven-digit fine from Honey, suddenly these costs are small potatoes.

I’m reminded of the old adage “never let a good crisis go to waste.”  Honey’s misconduct should bring real improvements to affiliate network compliance — arguably, well overdue.

In Reply to Honey’s Response

Last month, @megalag and I caught the Honey shopping extension not just violating affiliate network rules (failing to “stand down” in circumstances where networks so require), but intentionally tricking testers.  By checking users’ cookies (to see who had logged into a network’s admin console) and checking user account details (such as whether account was new or had few points), Honey could assess the likelihood that the user is a tester — and avoid breaking the rules when a tester was watching.

Honey today gave a statement to Hello Partner. In relevant part: “The code causing this behavior has been identified and no longer has an impact. The code was implemented prior to PayPal’s acquisition, and appears to affect less than 0.1% of Honey’s traffic.”

As to “implemented prior to PayPal’s acquisition”: The code is old, yes.  But Honey has changed the settings.  Acquisition was announced on November 20, 2019 and completed on January 6, 2020. Since then, Honey continued changing the selective stand down (ssd) settings. My article points out the ssd configuration as of June 2022, preserved by VPT, there instructing the Honey plug-in to not stand down in quite general conditions (requiring just 501 points for a Rakuten merchant, and requiring no specific number of points for any other network).  Yet by 2025, Honey’s config had totally changed these settings, requiring 65,000 points at most merchants.  Changing this setting, 4+ years after the acquisition — that shows PayPal staff knew what Honey had been doing.

As to “affect less than 0.1% of Honey’s traffic”: No doubt few users are affiliate marketing professionals with cookies showing recent login to an affiliate network console.  The number of such users is really besides the point.  The problem is that Honey affirmatively sought to trick industry pros and potential testers.  No matter or how few such people there were, these are the people whose diligent testing would have revealed Honey’s violations.  It was wrong to target them for different behavior, to try to trick them.  It was equally wrong whether they are 10%, 1%, 0.1%, or 0.01% of users.

After Dieselgate, investigation sought to determine which Volkswagen leaders knew what, when.  So too for Uber’s serious misconduct in 2017, prompting an investigation by former US Attorney General Eric Holder.  Rather than conduct a proper and independent investigation of what went wrong here, Honey seems to think it can self-certify its supposed clean-up.  I doubt the affiliate marketing industry will accept that.   If I ran a network that was contemplating letting Honey join, rejoin, or remain, I’d want to know the identities of the specific staff who requested, wrote, updated, and approved ssd, and I’d want assurance that they have been reassigned.  I’d want Honey to pay the network’s costs for the time and hassle of both historic investigation and future testing.  I’d want a genuine apology that admits responsibility without PR spin.  Honey’s statement to Hello Partner offers none of this.

Edelman v. Harvard – Summary Judgment Motions and Evidence

In 2023, I sued Harvard Business School, where I had been a faculty member for 11 years, for violations of the procedure it promised to use to review faculty conduct.  I say that if they had followed the procedure, I would have cleared my name of incorrect allegations.

Today I posted summary judgment filings and more than 1,200 pages of evidence.  My post offers hundreds of documents, summaries and reflections, a video explainer, and even an interactive AI chatbot trained on the filings.

In parallel with the summary judgment proceedings, I have a motion for sanctions for spoliation.  HBS amply knew litigation was likely, but delayed imposing a litigation hold for more than three years — during which key witnesses intentionally deleted key documents.  That’s spoliation — hence my motion.