Waindigo Install and Upgrade add-on call back sending list of ALL site add-ons

[Mouth]

Install and Upgrade by Waindigo

... says (in Overview) ...

In order to provide certain features of this add-on, the following information will be periodically sent to the Waindigo servers: a list of your add-ons, options relating directly to this add-on (does NOT include FTP details and stored credentials), current XenForo version, current language, debug mode flag, member count and board URL.

(emphasis - bold and font increase - added by me)

In this thread, I noted and waited for feedback, although Waindigo asked for the thread to be censored and mods locked it.

In the official Resource Guidelines discussion, I have suggested that a clause be added so that add-on callbacks can only be related to the add-on in question, and information sent is related directly to the add-on only.

Interested in other's thoughts on how far and how much information add-on callbacks should be allowed to send to home server?

 

[lostincable]

... says (in Overview) ...

(emphasis - bold and font increase - added by me)

In this thread, I noted and waited for feedback, although Waindigo asked for the thread to be censored and mods locked it.

In the official Resource Guidelines discussion, I have suggested that a clause be added so that add-on callbacks can only be related to the add-on in question, and information sent is related directly to the add-on only.

Interested in other's thoughts on how far and how much information add-on callbacks should be allowed to send to home server?

I get the potential need for analysis on what sort of board is using the add-on.

But to me I don't agree with it and for me personally I am checking all add ons Thoroughly.

If you want the details ask in a survey don't just expect it.

 

[Jon W]

The Install and Upgrade by Waindigo add-on checks all of a users add-ons to see if there are any updates available. For add-ons not listed for free on the Resource Manager, it works this out by checking the add-on ids against other people's add-ons they have installed (Waindigo and non-Waindigo).

For example, lets say you have Chris Deeming's Xen Product Manager add-on installed. When you update the add-on it notifies the Waindigo servers. Another site with this add-on then does its daily check for updates and receives a response to say that is an update available.

In order to provide this feature, the list of add-ons you have installed is sent to Waindigo servers.

The more people who use this add-on, the better it is for everyone.

There is nothing malicious about this.

In addition, the latest update sends the number of members on the site. In the vast majority of cases, this is publicly available information. This is used if the user is registered on waindigo.org as it lets the user know which upgrade package is most suitable. It also uses the number of Waindigo add-ons installed to calculate this. This information is used to determine whether premium features can be unlocked.

There is nothing malicious about this.

Both callbacks are to provide essential functionality in the add-on.

All of this information is fully available in the add-on listing, as has been quoted.

 

[HWS]

There are several forum installations using custom built add-ons with hidden features. We have a real lot of them at our forum. And I asume a lot of other XenForo installations have them too.

I, as a forum owner, would not like to have all those individual and custom built add-ons sent to a developer, who would be able to get his own ideas just by reading the titles of those add-ons. I am sure you do not do such things, but you (or anyone in your company) could.

Also I would not like to have other people know which add-ons I've installed at my forum. I don't know what happens with my data transferred to your server. Even if you don't do anything with it, even if you do not store it at all, your server could be hacked or a foreign person could gain access to it.

Also, as another developer I would not like to have the information about the customized add-ons, I coded for my customers, sent to you. I would also not be very happy if you know how many of my add-ons I've sold and to whom I've sold them. This is usually confidential and should stay confidential.

Chris D coded an Installer and Upgrader which does not need to have such information sent to his server. Maybe you want to think about going that way also? Or just use your installer for your own add-ons.

 

[Mike Edge]

I would not like to have all those individual and custom built add-ons sent to a developer, who would be able to get his own ideas just by reading the titles of those add-ons. I am sure you do not do such things, but you (or anyone in your company) could.

Also, as another developer I would not like to have the information about the customized add-ons, I coded for my customers, sent to you. I would also not be very happy if you know how many of my add-ons I've sold and to whom I've sold them. This is usually confidential and should stay confidential.

I might be wrong but I think going into the add-on options, there is a Ignored Add-ons section. Checking off the add-on, no longer sends info as it is no longer checked for updates. If I'm incorrect and it still does, then this idea should with out a doubt be considered since there would be no reason to data mine it at that point.

 

[HWS]

I might be wrong but I think going into the add-on options, there is a Ignored Add-ons section. Checking off the add-on, no longer sends info as it is no longer checked for updates. If I'm incorrect and it still does, then this idea should with out a doubt be considered since there would be no reason to data mine it at that point.

You think every developer should ask his customer to switch it off for each of his add-ons?
This is not very practicable.

Such a switch helps admins, which are sensible enough to protect their data. But such admins most likely would not install such an add-on anyway.

I know, Jon W can do what he wants. But this is a direction which raises much more concerns Jon W in his positive (christian) mind may even be thinking about. I would prefer him considering to find another way to find out which add-ons have been updated.

 

[Mike]

Chris D coded an Installer and Upgrader which does not need to have such information sent to his server. Maybe you want to think about going that way also? Or just use your installer for your own add-ons.

Worth noting that for a period of time, Chris's version was sort of indirectly DDoSing XenForo.com as we'd get a huge wave of connections all doing a lot of duplicate work at the exact same time. (It should be improved now, though older installs will still function that way.)

 

[HWS]

Worth noting that for a period of time, Chris's version was sort of indirectly DDoSing XenForo.com as we'd get a huge wave of connections all doing a lot of duplicate work at the exact same time. (It should be improved now, though older installs will still function that way.)

I know this is a problem for you, if every add-on updater parses your resources pages regularily. How about providing an XML feed with all official add-ons and their version number? Should be easy to extend the Ressource Manager to provide this feature. And I'm sure no developer would have a problem with it.

 

[Mouth]

In order to provide this feature, the list of add-ons you have installed is sent to Waindigo servers.

Negative. You only need a list of any add-on's not in XF's Resource Manager to provide this functionality. Otherwise, version numbers - free or paid - can be checked directly against XF Resource Manager, and not sent to Waindigo server.

There is nothing malicious about this.

Depends upon you interpretation of malicious. In might not be intending harm, but to me any data mining without very explicit/obvious and directly related reason is malicious. Collecting statistics on the full list of add-ons from a site, when - in the vast majority - version checking can be done by directly querying XF Resource Manager to me is opportunistic at best, potentially malicious at worst.

In addition, the latest update sends the number of members on the site. In the vast majority of cases, this is publicly available information. This is used if the user is registered on waindigo.org as it lets the user know which upgrade package is most suitable. It also uses the number of Waindigo add-ons installed to calculate this. This information is used to determine whether premium features can be unlocked.
There is nothing malicious about this.

So, the sending of site members from your add-on to your server is not related to your add-on providing any functionality but so that you can provide advisory services on your website for anyone that also has an account on your site.

Both callbacks are to provide essential functionality in the add-on.

Shown otherwise. Sending a complete list of a sites add-ons to your server is only provide functionality to the end-user when an add-on is not listed in XF Resource Manager. Sending the number of site members to your server is only providing functionality on your website, if the user has an account.

I believe both of these scenario's exploit the purpose and intention of XF's guidelines and rules on add-on call backs, hence why I've suggested they add an additional clause to clarify, and hopefully rule it out before a precedent is set.

 

[tajhay]

Does Chris Deemings Addon Installer still work? Im getting differring answers on that. I trust Chris so would rather use that to install my addons.

 

[TPerry]

For example, lets say you have Chris Deeming's Xen Product Manager add-on installed. When you update the add-on it notifies the Waindigo servers. Another site with this add-on then does its daily check for updates and receives a response to say that is an update available.

In order to provide this feature, the list of add-ons you have installed is sent to Waindigo servers.

Then let's say I use your add-on installer... and I am BETA testing Showcase and AMS, and other add-ons. I install the new BETA version... and YOUR add-on installer then goes and counts it as an update and falsely alerts people that there is a new version... or am I understanding you incorrectly or do you have code in place that will exclude any BETA software packages that you don't know about?

 

[TPerry]

Does Chris Deemings Addon Installer still work? Im getting differring answers on that. I trust Chris so would rather use that to install my addons.

Works fine for me.. with the exception of some of the larger add-ons.. you may get an error at first run (from what I understand it's due to the XML being ran before all files have extracted onto the server instance - running the XML a second time correctly installs it all).

 

[Sheratan]

Maybe waindigo server check to xenforo, then user check to waindigo server. If the version is not same, then some kind of flag is created. So waindigo create addon database based on xenforo, not people who callback to waindigo server.

 

[Mike Edge]

Does Chris Deemings Addon Installer still work? Im getting differring answers on that. I trust Chris so would rather use that to install my addons.

works fine with suPHP handler, it doesn't work under FastCGI due to the handler using nobody:nobody which results in denying permission to create a new temp directory.

 

[Daniel Hood]

Not saying there aren't legitimate concerns here but.. first ******* now jon, who's next?

 

[Mouth]

Does Chris Deemings Addon Installer still work?

Working fine for me

 

[Mouth]

Not saying there aren't legitimate concerns here but.. first ******* now jon, who's next?

That's the premise of continual improvement.

Call-backs are allowable, within constraints, by XF for listing in the Resource Manager. But they don't check/audit any add-on code using call backs, so it's all discussion, investigation, and reactive action. We have to be able to discuss, with examples, when the bounds of call backs are used, IMHO, outside the intention of XF's guidelines for them. The Resource Guidelines are not clear in what information an add-on call-back can send to a home server, and I believe it's need clarifying/quantifying.

For the protection of the XF community (admin and users), I'm hoping that XF clarifies and says that call-backs can only send information that is directly related to that add-on only, and never wider statistics about your server or XF installation.

It's a precedent that I believe XF should say is within resource guidelines or not, and if so how much further information about your site can be sent.

 

[tajhay]

I'm hoping that XF clarifies and says that call-backs can only send information that is directly related to that add-on only, and never wider statistics about your server or XF installation.

I too am hoping this guideline becomes mandatory for all addons placed on the RM here.

 

[TPerry]

works fine with suPHP handler, it doesn't work under FastCGI due to the handler using nobody:nobody which results in denying permission to create a new temp directory.

yeah, it does present a problem for folks that use LS and cPanel setups. For those of us on a VPS/dedi with full control that problem is not a problem.

 

[Daniel Hood]

That's the premise of continual improvement.

Call-backs are allowable, within constraints, by XF for listing in the Resource Manager. But they don't check/audit any add-on code using call backs, so it's all discussion, investigation, and reactive action. We have to be able to discuss, with examples, when the bounds of call backs are used, IMHO, outside the intention of XF's guidelines for them. The Resource Guidelines are not clear in what information an add-on call-back can send to a home server, and I believe it's need clarifying/quantifying.

For the protection of the XF community (admin and users), I'm hoping that XF clarifies and says that call-backs can only send information that is directly related to that add-on only, and never wider statistics about your server or XF installation.

It's a precedent that I believe XF should say is within resource guidelines or not, and if so how much further information about your site can be sent.

I've never used his add on, or chris' comparable add on for that matter, for this reason. It clearly states exactly what it's doing, if you don't like it don't use it. The difference here is that he's now tied this add on with an undesirable method (in most people's opinion) to his other 200 add ons. I can see how it might be an issue but the fact it's clearly stated and isn't executing any code makes it in compliance with the policies.