Apparently Samir Meghani at the Bountii Team Blog decided on surrendering to Microsoft and Bing Cashback. Sadly for Microsoft, their lawyers was too dumb to make sure the same content was removed from Microsofts own “search engine” cache.
http://cc.bingj.com/cache.aspx?d=4879267570255838&mkt=en-CA&setlang=en-US&w=90157511,9ea4ebc5
Update: Microsoft removed it from Bing cache
Just in case they should grow a clue, here’s the description of the technical problem that Microsoft, in its infinite wisdom, decided to correct with lawyers instead of software engineers:
I’ve never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Let’s see how these transactions might have “accidentally” got credited to my account.
First, we need to try to figure out how transactions get into Bing Cashback. Microsoft posted some documentation here. The explanation of how a merchant reports transactions to Bing starts on page 20. Merchants have a few options for reporting, but Bing suggests using a tracking pixel. Basically, the merchant adds a tracking pixel to their order confirmation page, which will report the the transaction details back to Bing. The request for the tracking pixel looks something like this:
https://ssl.search.live.com/cashback/pixel/index? jftid=0&jfoid=$ORDERID&jfmid=$MERCHANTID&m[0]= $ITEMID&p[0]=$PRICE&q[0]=$QUANTITY
This implementation, while easy for the merchant, has an obvious flaw. Anyone can simulate the tracking pixel requests, and post fake transactions to Bing. I’m not going to explain exactly how to generate the fake requests so that they actually post, but it’s not complicated. Bing doesn’t seem to be able to detect these fake transactions, at least not right away. The six cents I earned in January have “cleared,” and I’m guessing the remaining $2080 will clear on schedule, unless there is some manual intervention.
Even if Bing detects these fake transactions at some point in the future, the current implementation might have another interesting side effect. I haven’t done enough work to say it with confidence, but a malicious user might be able to block another user’s legitimate purchases from being reported correctly by Bing (I only tried this once, but it seemed to work). Posting a transaction to Bing requires sending them an order ID in the request. Bing performs a reasonable sanity check on the order ID, and will not post a transaction that repeats a previously reported order ID. When a store uses predictable order ID’s (e.g. sequential), a malicious user can “use up” all the future order ID’s, and cause legitimate transactions to be ignored. Reporting would be effectively down for days, causing a customer service nightmare for both Bing and the merchant.
Based on what I’ve found, I wouldn’t implement Bing Cashback if I were a merchant. And, as an end user and bargain hunter, it does not seem smart to rely on Bing Cashback for savings. In our next blog post, I’ll demonstrate some other subtle but important reasons to avoid using Bing Cashback.