Lee

Released: ApexDC++ 1.3.3

17 posts in this topic

Today we announce a maintenance update to our stable branch. It includes important fixes from DC++ and StrongDC++, with a few fixes of our own. We have also tweaked the behaviour of the update check to allow people more freedom to upgrade. If you select "Later" in the update check it will not remind for another three days. Plugins used for 1.3.2 should run on 1.3.3.

We have had a decent amount of applicants for our listed jobs, but we're still looking for help porting to Linux.

Share this post


Link to post
Share on other sites

Want to run ApexDC++ with multiple tray icons? Download the pack below, select a colour, rename to "app.ico" and place it in ApexDC++ folder.

ApexDC_ico.rar

Share this post


Link to post
Share on other sites

We have also tweaked the behaviour of the update check to allow people more freedom to upgrade. If you select "Later" in the update check it will not remind for another three days.

Is a third party, who happens to be a for-profit corporation that (nearly) no Apex users have any contract with, still contacted each time the user starts Apex with this change?

Share this post


Link to post
Share on other sites

Is a third party, who happens to be a for-profit corporation that (nearly) no Apex users have any contract with, still contacted each time the user starts Apex with this change?

This has never been done... the connection that is made is made to web space that is under our control and all that happens is that an xml file, for the update check, is downloaded and parsed by the application... the file itself is never even saved on your hard drive.

If you or someone else has been using a version that connects to some for-profit third party, then I suggest that you check where you get your executables from. Also I would be more than a bit interested in what this for-profit corporation is?

Share this post


Link to post
Share on other sites

This has never been done... the connection that is made is made to web space that is under our control and all that happens is that an xml file, for the update check, is downloaded and parsed by the application... the file itself is never even saved on your hard drive.If you or someone else has been using a version that connects to some for-profit third party, then I suggest that you check where you get your executables from. Also I would be more than a bit interested in what this for-profit corporation is?

The connection is made to a Sourceforge server (from the strings in v1.3.2 it looks like apexdc.sourceforge.net, and update.apexdc.net from the v1.3.3 source), which whilst may be accessible by you guys, is ultimately controlled by Sourceforge. SF will have access to your logs (or would be able to create their own on their load-balancing proxies), so would be able to infer information about Apex usage and users if they wanted to. Sourceforge is owned by Geeknet Inc., a publicly traded corporation. I get my Apex exes from the same place as everyone else: Sourceforge's servers.

My gripe is that the application phones home when started, and this behaviour cannot be turned off (by the average user). I know the justification for why the application downloads an XML file at each start-up, but it is still a privacy violation. If your bank decided that postcards would be cheaper to deliver your bank statements than envelopes (and pass on the savings to you in the form of better interest rates), then I'm sure you wouldn't be happy with the potential privacy violation. Your postman probably doesn't give a shït about your bank account, and SF probably don't give a shït about Apex users, but it is the principle of it. It is no ones business, but the user's, how often and when Apex is run.

It also looks like Apex supports the ability to download something, and execute it, possibly all based on the content of the XML file. If your server gets owned, it could mean Apex users subsequently get owned. This mechanism needs to be turn-off-able at the very least!

Whilst grep'ing the source, I also noticed that Apex's web interface uses style sheets served from www.apexdc.net, meaning the referer sent to you will contain the user's possibly private server address. I feel any supporting files for the web interface should be served totally from the user's computer. The user would be able to easily modify the web interface if they wanted, too.

Share this post


Link to post
Share on other sites

Then how come you can browse this website? You know, behind every website there is a for-profit corporation if you dig deep enough. And as generally with websites you (the users) are not bound by any contracts to these companies and/or organisations... we are the ones that are bound by contracts and agreements in using their services (and paying a fair bit for it too in case of www.apexdc.net) to serve content to users, not you.

Sure logs are kept but the logs that are made are the same ones that get if you point your web browser over to those locations. I am aware that web browsers can use proxies, but ApexDC++ can do this too. The option is in settings, although I admit it is not very sophisticated and that it is named in a bit misleading way as while it speaks only about public hublists that proxy affects al htttp connections made by ApexDC.

My gripe is that the application phones home when started, and this behaviour cannot be turned off (by the average user). I know the justification for why the application downloads an XML file at each start-up, but it is still a privacy violation. -- and SF probably don't give a shït about Apex users, but it is the principle of it. It is no ones business, but the user's, how often and when Apex is run.

Using the term "phones home" in this case is pretty harsh because, as you can see from the source code, the intent of downloading the xml file is not to distribute information about users or usage of ApexDC but to deliver notifications about software updates. Feature which can be found in countless applications and most likely works by using similar principle in all cases. Also if you download your executables from SourceForge then in doing so you already leave a trace in their logs, how come you can do this?

It also looks like Apex supports the ability to download something, and execute it, possibly all based on the content of the XML file. If your server gets owned, it could mean Apex users subsequently get owned. This mechanism needs to be turn-off-able at the very least!

Now that is a fancy way to describe the automatic updates feature, which is turned off for now and there is no immediate plans to turn it on, which is another feature that is common to many applications and this feature is completely optional even if it was turned on.

Regarding our server getting "owned" we are naturally not planning to let this happen easily but just as those two features above are shared among countless of applications the risk of something like this happening is equally shared among all of them. Also the cases where our server (or control over of our SF project facilities) could get compromised are limited and as a matter of fact you, as a user, can assist in one of those cases never coming reality by making sure you do not infringe anyones copyrights while using ApexDC++.

Share this post


Link to post
Share on other sites

A nice and unexpected release. Good work!

Share this post


Link to post
Share on other sites

We have just upgraded the forums to IPB 3.1. There's a few changes such as social integration, new search and performance should be better.

Report any problems you've seen and we will try and resolve them.

Share this post


Link to post
Share on other sites

My gripe is that the application phones home when started, and this behaviour cannot be turned off (by the average user). I know the justification for why the application downloads an XML file at each start-up, but it is still a privacy violation.

I agree auto update should be able to be readily disabled by the user, ApexDC then having no reason to phone home.

I use ApexDC only on an internal network, unmetered by my ISP, and strongly prefer ApexDC accesses no addresses outside this private range.

I enforce this via my PC firewall, which does prevent ApexDC from phoning home atm.

Share this post


Link to post
Share on other sites

I agree auto update should be able to be readily disabled by the user, ApexDC then having no reason to phone home.

I use ApexDC only on an internal network, unmetered by my ISP, and strongly prefer ApexDC accesses no addresses outside this private range.

I enforce this via my PC firewall, which does prevent ApexDC from phoning home atm.

K but being exploitable or exploited is something that we (the core of direct connect development) wants to stop and if i got my way i would have done the same as the apex team and having forced updates since users can often be lazy when it comes to updates...

Share this post


Link to post
Share on other sites

I agree auto update should be able to be readily disabled by the user, ApexDC then having no reason to phone home.

I use ApexDC only on an internal network, unmetered by my ISP, and strongly prefer ApexDC accesses no addresses outside this private range.

I enforce this via my PC firewall, which does prevent ApexDC from phoning home atm.

Grab the source and compile your own version.

Share this post


Link to post
Share on other sites

Thank you all for your hard work on this version and for previous versions. In the past this client has been a boon to hub owners and clients who value their privacy and security.

I too am reluctant trust an application which forces me to update or those which check on their status unprompted.

while i am happy that the new version gives me the option to delay my decision I would rather make the choice to check for updates myself.

Hub owners often use private hubs and are leery of new versions and refuse their use in their hubs.

Please consider the concerns raised by those who oppose the current update feature and incorporate the option to opt out of the update feature.

I always check for updates via email notification and take seriously those updates offered. A client that is not accepted in hubs is likely to be found out of favor quickly and dropped en-mass.

Share this post


Link to post
Share on other sites

There is no reason for private hubs not to upgrade. We have contact with a lot of them and they upgrade each time.

Updates are forced for users and network security. Simple as that... if you don't like it I suggest moving to a project that allows you to run outdated and potentially harmful software.

ApexDC++ will always automatically check for new updates to keep older versions out of DC.

Share this post


Link to post
Share on other sites

First thanks fpr ApecDc++.

To the thing with the forced auto update. I am alright that the software checks for updates, but i am not alright that i have to do it even i only want to check if someone online on my private hub. But my prob would be harmless, if you add that apecdc++ downloads the files itselfs, when you say okay "upgrade now" or sth. like that.

In any way go so on.

Share this post


Link to post
Share on other sites