Statistics aside people seem to discount the fact that centralizing it to your own server actually reduces the load on XenForo.com.
Ignoring XenForo.com specifically, it's just an efficient way to do it. If I were in
@Jon W 's position, it's not an unreasonable approach. Here, I'm referring specifically to sending a list of installed add-on IDs and version IDs to his server and having it respond with update information. Attempting to have each add-on check for an update is incredibly slow and scraping is notoriously fragile; being able to control that internally is a benefit to maintenance and ultimately good for anyone using it (the alternative is it breaking until you upgrade the add-on itself, when you might not know it has broken because the update check itself is now failing). It also means that you can track changes at the version ID level rather than the visible version which might differ from what's in the add-on itself. From a developer standpoint, it's a superior approach across the board aside from having to maintain the service to run it (which isn't necessary if scraping XenForo.com directly).
Then there's the problem of add-ons that aren't hosted here so you can't really identify those as being updated in the same way as ones that are hosted in the resource manager here. That leads into the "crowdsourcing" idea of using the aggregates of installed versions to detect when they're updated. It's a nice idea to solve a problem with a class of resources that might otherwise be hard to "access" like the ones hosted here.
The point I'm making is that the way Jon's install/update add-on has (presumably) been approached is focused on providing a good technical solution to a problem. And it does solve some issues that exist with the scraping approach. Obviously I can't speak to his motives definitively, but to jump to "it's making a request from his server so it's evil" is a stretch or at least hyperbole.
It reminds me of some of what was reported with the Facebook Android app permission changes. "Facebook will be listening to you talk all the time." Technically, that may have been true based on the permission, but it's the nature of how permissions work in general. If you want a feature that requires some sort of activity (as determined by the developer's solution), then you have to accept and trust how they'll use it; if you don't, then really you shouldn't be installing any code from them whatsoever. The same permission or activity can simultaneously be used for good and evil; there is no
evil bit that can detect this. Changing the font and color in a post can be used for both good and
evil but this can only be judged by a human and even then there's debate.
Forget about callbacks, have you audited all of the code you've installed from other developers? How about XenForo itself? You're running arbitrary code on your server and it can do all sorts of things without callbacks. If you haven't (and I'm sure most of you haven't), then you're trusting the developer. You can take this further through the stack all the way to the kernel of your operating system (and then the actual hardware, see the
Dual_EC_DRBG discussion).
Now whether the approach of sending add-on IDs to his server is one you're willing to accept is a reasonable question, but it is not inherently evil. It's evident that this discussion has somewhat adjusted Jon's perspective on it and probably brought up considerations he hadn't thought of. (Personally, I can't imagine I wouldn't have thought of "private" add-on IDs off hand. It makes sense in hindsight but may not be a thing you'd consider before running into it and, even then, you may not realize that people would have concerns about it.)
To say that add-ons should only be able to send their own data to a server blocks entirely valid and useful add-ons while probably not giving a great benefit. If you take that to its end, you just blocked Akismet or StopForumSpam implementations. You even just prevented an add-on from sending a reference to the URL where its been installed (since that's not the add-on's data).
The reason we require callbacks to be declared is to allow you to make your own decision if it's an issue you are concerned about. If you don't like the data being sent, you're certainly entitled to tell the developer that and vote with your feet; equally, they're entitled to not change anything. It's also important to make you aware if the add-on depends on an external server for something such as license validation (or premium enabling); depending on the implementation, this may start to fail if the developer closes shop. This is a risk you would need to understand and accept.
Coming back to the install/upgrade add-on, whether the premium upgrades should be included as part of this and whether things like member count should be collected are reasonable questions to ask Jon and for him to respond to. Personally, it seems strange to conflate the two things; the overlap seems to be that they both depend on add-on IDs but not much else. It seems like it would make sense to create a "premium feature enabler" add-on that applied to all Waindigo add-ons and that could simply be installed to enable premium features; this add-on would then just send back installed Waindigo add-on IDs and (assuming the member count-based tiers are kept) the member count. The callback clearly declared in the resource description, of course. That seems to solve most of the concerns. (Unless you're fundamentally opposed to callbacks and/or the member count stuff, but then that would be a good example of making a stand because you disagree and simply not purchasing anything.)
