We have had a decent amount of applicants for our listed jobs, but we're still looking for help porting to Linux.
Released: ApexDC++ 1.3.3
#1
Posted 14 June 2010 - 09:48 PM
We have had a decent amount of applicants for our listed jobs, but we're still looking for help porting to Linux.
#2
Posted 14 June 2010 - 10:19 PM
Attached Files
#3
Posted 14 June 2010 - 10:21 PM
#4
Posted 14 June 2010 - 10:29 PM
Lee, on 14 June 2010 - 09:48 PM, said:
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?
#5
Posted 14 June 2010 - 10:43 PM
9u8y7t6rdxf, on 14 June 2010 - 10:29 PM, said:
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?
#6
Posted 15 June 2010 - 12:35 AM
Crise, on 14 June 2010 - 10:43 PM, said:
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.
#7
Posted 15 June 2010 - 08:43 AM
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.
Quote
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?
Quote
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++.
#8
Posted 15 June 2010 - 01:26 PM
#9
Posted 15 June 2010 - 04:03 PM
#10
Posted 16 June 2010 - 09:49 AM
#11
Posted 16 June 2010 - 08:19 PM
Report any problems you've seen and we will try and resolve them.
#12
Posted 24 June 2010 - 01:02 PM
9u8y7t6rdxf, on 15 June 2010 - 12:35 AM, said:
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.
#13 Guest_Toast_*
Posted 24 June 2010 - 05:01 PM
patch1, on 24 June 2010 - 01:02 PM, said:
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...
#14
Posted 25 June 2010 - 07:46 PM
patch1, on 24 June 2010 - 01:02 PM, said:
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.
#15
Posted 07 July 2010 - 04:34 AM
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.
#16
Posted 07 July 2010 - 09:27 AM
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.
#17
Posted 21 July 2010 - 07:32 AM
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.
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users












