I just updated my iPhone app. Next time I launched it, a splash screen encouraged me to log in to my Google Account, but offered a link to use Authenticator without a Google account. There's a slashed-through cloud icon at the top of my screen. When I tap it the app notes "Your codes are not being saved to your Google Account".

Hey, look. we're talking about Wordle again. And mentioning its deep-pocketed patron by name.

Please post your experience. I decided to test iCloud+ custom domain email yesterday with a domain that didn't already have email service and Apple's web UI would not let me assign email addresses for any other family members. It appeared that the only way anyone other than me (the Family "Organizer") could use the custom domain would be to have already set up a working email address for that domain with some other mail provider -- either you provide each family member's currently working email with the custom domain and wait for them to confirm their receipt of a verification email, or you can only use the custom domain for yourself.

So I expect not to use iCloud+ custom domain even though I'm already paying for iCloud+. The configuration problems and support runaround (the company's worth $2.6 trillion, has $196 billion cash on hand, has been taking my subscription & hardware money for years & can't talk with me until two days from now?) bring back too many memories of other terribly disappointing Apple software experiences that I've had at work, with their web UIs for things like Apple Developer accounts not working as documented. I'd love to keep paying $0 more than now for my personal/family email, but I don't think I can trust Apple iCloud+ for this.

From what I've seen, most of these bugs are really obscure and only apply to unusual, specific circumstances. Consider https://snyk.io/vuln/npm:jquery:20150627 -- to be vulnerable, your web page has to be making an $.ajax() call to a malicious cross-domain server.

This may be a better example, for jQueryUI (not jQuery core): https://snyk.io/vuln/npm:jquery-ui:20160721 -- to be vulnerable, you have to create a dialog box object and use browser-supplied data in the Close Text property. 99.99% of the time close text is canned content: "OK", "Done", etc. This vulnerability is labeled a High risk but it's completely irrelevant to the vast majority of websites using jQuery UI.

If all you're doing with jQuery is $('#myspan).text('Hello world'); then you are not at all vulnerable to those flaws (or any other jQuery flaws I've read about).

I think the bigger issue here is the jQuery maintainers aren't backporting fixes to old releases, and likely aren't publicizing (or perhaps even aware of) other flaws in end-of-life jQuery releases. Just as you wouldn't assume Internet Explorer 6 was safe to use because nobody has published a new exploit in years, you shouldn't assume that jQuery 1.4.x is safe because nobody has reported relevant flaws in it.

Plus, you know, if there are bystander injuries, help should be readily available.

A reasonable way: both of the existing ones. The tracking pixel is used to provide instant user update in 99% of the cases, but the transaction is marked pending. At the end of the day the text list is uploaded to the FTP. Compare the 2 lists, approving all that match and flagging for review any that don't (extra, missing, or different).

Exactly. And I wonder if they've done that already, and simply not updated their integration docs. There's no way to pass a transaction date with the pixel, so Bountii must've first played with this back in January. It would've been nice to know how long the Jan 24 forgeries took to clear. The fact that the Oct 24th purchase hadn't become Available by Nov 4th suggests that Bing might now require batch confirmation for all transactions. Or perhaps the merchant used the Merchant Center interface to flag the transaction -- I know in the ecommerce systems I've been involved with, staff review the transaction log for anything unusual.

There is still that Denial of Service problem -- a user claiming all "future" order IDs and preventing legitimate customers from getting their credits. I thought Bing might've simply prevented any given customer from submitting two claims with the same merchant ID & order ID (classic "transaction token"/page reload stuff), but the screenshots of the Merchant Center suggest that Bing isn't dong that (yet).

My favorite part is that on page 20 of the Bing Cashback integration guide they say that the pixel hack is "recommended" for reporting purchases. Recommended!

Second favorite: that Samir at Bountii posted this on his blog without contacting Bing first. He should've followed something like the RFPolicy protocol (http://www.wiretrip.net/rfp/policy.html).