Okay, I'm getting to grips with what they've done with the core honey pots
They have implemented quite a lot that was in this original FoolBotHoneyPot add-on, they have also missed some important things out... the POST to registration page should really go to a unique url (users never saw this), this has been missed out completely, but they do use a regKey (which has issues)
There code is cleaner (they are far cleaner code writers than I). They have implemented many of the things I had done, but while the code is clean the implementation of ideas is weak, and I understand how Xrummer are now looking to target this.
For instance,
1) The regKey that they use is not truly unique it's just md5(uniqid('xf', true)); if we know the exact millisecond or the time range... we know the expected regKey, and with automation that sort of trial and error is child's play. They could/should use something that is unique to that particular forum but not exposed, for instance the forum purchase id (if it was gettable by code)
2) The front end hidden methods are weak (they use very few methods to hide, 1 in fact, and use the same method all over). display: none; over and over . Previously I used 3 other methods that are much harder to detect that they're hidden. I will add these back in, since display:none is so easy to bypass (z index takes some logic in their automation, as do off screen items, far more tricky to target)
3) They use this methods at the same css node level using the same css style name, that makes it super easy to target (they should be using inline uuid style names to make it hard to target)
4) There is a massive issue with how they implement ordering of fields, sometimes none are even present due to the use of <xen:if is="mt_rand(0, 2) == 1"> to "randomise the order"... if 21 million bots attempt the honey pots, there will be 1 millions that do not even get tested against a honey pot... that's poor thinking this through.
5) Haven't figured out their logging yet, but I don't think there is a session cache or global cache for attempts, so infinite bot attempts without even needing to change session or IP address. That makes things easy for bot developers
6) No htaccess update, so bots endup taking a fair amount of db usage and kb resources due to large number of attempts
Ignoring these issues, it is still all very easy to by pass. Good clean code, poor implementation of ideas, I wish they had consulted with me at least once, they could have done a much better job and pushed back targeting for quite some time.
Also, as far as I can see, they have done nothing to help people that use username/password loger plugins ... So there is no point in me using my original methods from previous version (since the core won't allow them any more anyway).
XenForo dev are amazing developers, I've learnt so much by extending on their well written MVC code and brilliant designs, but they're not experts of Automation, they can't be experts of all areas I guess.
Just some first thoughts after looking a little deeper at what they've done with honeypots
A lot to do, a lot to improve before I even think about adding the new magic ingredients.