Would you find this acceptable (or class it as SpyWare)?
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
A comment to add to what others have said above.
Second, I would have an option in your options dialog to choose one of:
- Always check for updates
- Prompt before checking for updates
- Never check for updates
I would install by default with the "prompt" option, which I imagine popping up a dialog before checking for the update, that says something like, "Buzzworx is about to check for an update on the network. No personal information will be sent to the Buzzworx home. Press 'OK' to proceed, or 'Cancel' to skip checking for updates." The dialog could also have a "Don't display this message again" check box (similar to the ones MS uses for tip-of-the-day dialogs), which would then set the option to "always" or "never" depending on whether the person clicks "OK" or "Cancel"
From a useability perspective, this design is quite similar to the privacy and security user interface IE uses, so it will be familiar to users.
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
we are also looking into this idea as we have a lot of corporate clients who do not really understand or care what updates might do that benefits them ... we also use the scheme to lock out clients who don't pay their fees in a reasonable time ... sounds draconian but otherwise you end up being a charity organization "every year we invent better idiot proof systems and every year they invent better idiots"
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
a number of commercial apps that i own do similar things, and i have no problem with it. some of them do the update test when you launch them. they check a server (it could be as simple as an http request, i dunno) and tell me if there's an update available. so, the initial connection is done without my approval. it doesn't bother me. other programs (virus checkers, eps) can be scheduled to check for updates. this is fine with me, too. i think as long as you make it clear to the user that you are testing for updates (and provide a way to disable it!!) most people will be fine with it. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
Give the user the option to turn this on and off (Help menu->Autocheck for updates). Make your dialog very clear that no personal information is sent back. Give the user the option via the help menu to manually check for updates (ala Windows Update). Other than that, sounds ok. --------------------------------------------- Todd Wilson (tw@nopcode.com) www.nopcode.com ICQ: 5638028 "I picked up a Magic 8-Ball the other day and it said 'Outlook not so good.' I said, 'Sure, but Microsoft still ships it.'"
-
we are also looking into this idea as we have a lot of corporate clients who do not really understand or care what updates might do that benefits them ... we also use the scheme to lock out clients who don't pay their fees in a reasonable time ... sounds draconian but otherwise you end up being a charity organization "every year we invent better idiot proof systems and every year they invent better idiots"
we are also looking into this idea as we have a lot of corporate clients who do not really understand or care what updates might do that benefits them. This was our major problem. Any updates (and I expect there will be some) could contain very important bug fixes, and even new features. What I daon't want to happen is for the end user (or company) to be using a product which has 'this bug' and 'that bug' in it, when the bug has already been fixed. The problem then is when they might be deciding to pruchase another product from us they will have "well, the last product had this bug and that bug in it and they never bothered to fix it". If only people would just take your word that you would not violate their privacy. Unfortunately nowadays we live in a world where nobody ever believes what anyone else says anymore :(. David Wulff dwulff@battleaxesoftware.com
-
we are also looking into this idea as we have a lot of corporate clients who do not really understand or care what updates might do that benefits them. This was our major problem. Any updates (and I expect there will be some) could contain very important bug fixes, and even new features. What I daon't want to happen is for the end user (or company) to be using a product which has 'this bug' and 'that bug' in it, when the bug has already been fixed. The problem then is when they might be deciding to pruchase another product from us they will have "well, the last product had this bug and that bug in it and they never bothered to fix it". If only people would just take your word that you would not violate their privacy. Unfortunately nowadays we live in a world where nobody ever believes what anyone else says anymore :(. David Wulff dwulff@battleaxesoftware.com
agreed we develop products for the financial markets worldwide and as such building a relationship with clients is as important (nearly) as supplying software our clients just want the thing to work and tend to trust us to some degree which allows us to do things maybe other situations wouldn't having said that we get price files and such from the internet as an integral part of the product so checking if they paid their subs is cool and transparent ... upgrade notifications are given with an option to download them which they tend to like as it appears like magic to most of them my approach to business is that if i don't trust my clients (or they don't trust me) i won't want to do business with them :) "every year we invent better idiot proof systems and every year they invent better idiots"
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
David, Pardon any of my ignorance, but how do you intend to "look to see if the user is connected to the Internet". Just cause there is a network card in the machine and just cause there is a TCP/IP stack setup, doesn't mean any packet you send is going to find your "secure server". I suspect that most corprate and/or personal firewalls are going to typically going to block such attempts to send data out from behind the firewall. Certainly trying to do this and to not be seen as BIG BROTHER, is going to be both a challenge functionally and technically. Chris Meech
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
Hi there! I agree: the best is to give the users a choice! But concerning the update process: why don't you do it the other way round without UPloading anything? I prefer DOWNloading the newest version number at program start (or whenever) from a certain server/port and let the CLIENT compare it to it's version. If then an update seems necessary pop up a diaglog asking the user to do it now, later,... This way I can declare my software as not UPloading anything (expect requests :) and don't have to care about spy-stuff :) Greets Scoop
-
Hi there! I agree: the best is to give the users a choice! But concerning the update process: why don't you do it the other way round without UPloading anything? I prefer DOWNloading the newest version number at program start (or whenever) from a certain server/port and let the CLIENT compare it to it's version. If then an update seems necessary pop up a diaglog asking the user to do it now, later,... This way I can declare my software as not UPloading anything (expect requests :) and don't have to care about spy-stuff :) Greets Scoop
That is what our current idea does. The only thing that is (in your analogy) UPloaded, is a single request containing the users program version. Then if an update to that version is available, the user will be given the option to DOWNload the upgrade files and install them. And anyway, to downlaod the current version number to the clients machine and then comapre it locally would surely not gain anything. The version number sent to the secure server is hardly user-unique, so it couldn't be used to 'spy' on the user anyway. Or am I just missing your point completely? David Wulff dwulff@battleaxesoftware.com
-
David, Pardon any of my ignorance, but how do you intend to "look to see if the user is connected to the Internet". Just cause there is a network card in the machine and just cause there is a TCP/IP stack setup, doesn't mean any packet you send is going to find your "secure server". I suspect that most corprate and/or personal firewalls are going to typically going to block such attempts to send data out from behind the firewall. Certainly trying to do this and to not be seen as BIG BROTHER, is going to be both a challenge functionally and technically. Chris Meech
You can solve the firewall problem by using the standard protocol like HTTP(S). In this case your software will get the HTML page with the latest version information inside and if it requires an update, it can be downloaded using HTTP too... Alex.
-
That's exactly what I was going to suggest as well - as ask at first run, if they say 'no' point them to the preferences if they change their mind. I'd probably also store the date in the registry and ask again, in a more detailed manner ( something like 'Do you realise you've not checked for an update for xxx, would you like to now ?' ) at an appropriate interval ( I'm thinking no less than six monthly and possibly even yearly. The software could also perform this check when first run, based on how old the build is, which I've seen before ( 'This software is 2 years old, would you like to check on-line for an update ??' ) Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
If I may add. I believe users education and making them aware of your action as clear as possible is your best choice. I was very surprised to see that thier was a security user account called Support on the Beta 1 of whistler machine I have installed for testing. Since I was not aware of it in advance the first thing I did was disabling it. for sure when I get more info about this account and what rpivliges does it have I might enable it. On the other hand, to have my application shows up in the netstat along with NetBus or BackOrfice will not empress the user if they are not aware and would generate more heated tech calls than you might want. Once again I highly recomending making it as clear as possible to the user. cheers Alfadhly
-
David, Pardon any of my ignorance, but how do you intend to "look to see if the user is connected to the Internet". Just cause there is a network card in the machine and just cause there is a TCP/IP stack setup, doesn't mean any packet you send is going to find your "secure server". I suspect that most corprate and/or personal firewalls are going to typically going to block such attempts to send data out from behind the firewall. Certainly trying to do this and to not be seen as BIG BROTHER, is going to be both a challenge functionally and technically. Chris Meech
It is possible to see if the client's machine is currently connected, by using PJ Naughter's CRasMonitor::RasGetConnectStatus(...) class/function which does all the work for you. It uses different ways to obtain the connection info such as examining the connection status in the regsitry and using RAS32.DLL (or whatever it is called). And if the user is behind a firewall, they will be prompted to connect through a proxy to try to avoid those problems. Of course though, if the machine is part of a network and the admin wants control over the updating process (very likely) they will probaly disable update-checking and do it manually when an update is available. Having the update downlaoded for each workstation would be a waste of bandwidth, and if you pay for your internet connection, a waste of money. Certainly trying to do this and to not be seen as BIG BROTHER, is going to be both a challenge functionally and technically. Not so much in those cases, but it will be a challenge to prove honest intent to these people who are paranoid that all companies are bad, and want to exploit your personal information. - I have a friend how wont even save any documents on his machine as he believes they will not be secure. So he uses floppy disks and his laptop for everything, and the only data installed on his PC are games and the OS. David Wulff dwulff@battleaxesoftware.com
-
That is what our current idea does. The only thing that is (in your analogy) UPloaded, is a single request containing the users program version. Then if an update to that version is available, the user will be given the option to DOWNload the upgrade files and install them. And anyway, to downlaod the current version number to the clients machine and then comapre it locally would surely not gain anything. The version number sent to the secure server is hardly user-unique, so it couldn't be used to 'spy' on the user anyway. Or am I just missing your point completely? David Wulff dwulff@battleaxesoftware.com
I doing HTTP based version checking in the new version of ED4W and I've been surprised and how sites where this doesn't work. I assume that it is being blocked by a firewall or an in some cases personal firewall apps like ZoneAlarm. Certainly from my experience so far you can't assume this will work for all users and at a guess I'm seeing around 50% of sites where it works. I'm only doing a HTTP GET to download a 20 byte plain text file. I can't see any reason why you'd want to upload a file to a server and get it to do the comparison for you. As an end user I'd be more suspicious if even a single byte was being sent from my PC. I agree with all the previous comments about how to go about making it optional etc. I'd be most interested to hear of the experiences of others using Internet based version checking with regard to percent of customers where it works/doesn't work. Neville Franks, Author of ED for Windows www.getsoft.com
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
Hi David, basically there is nothing wrong with what your software does if it really doesn't store any information about the user's computer. It is a feature. But from usability point of view you have to take care that user feels in control. Therefore you have to include possibility to turn this option off. I recommend following possibilities to turn it off: 1.a) At installation 1.b) The first time the application runs, I'd recommend installation, because first runs are usually times of anxiety :-) (let me see, let me see, let me see...) 2) In Options from the main menu (part of software's configuration) and 3) When an update is available and you ask user to perform it there should be a checkbox saying "Do not perform this check in the future..." in the dialog (it's standard). And an example of BAD design. My MSN messenger keeps on reporting new version available with a checkbox saying "Do not ask me this question for a week."... Annoying. MSN is started every time I turn on the computer. Even more annoying. Regards, Tomaz
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
David, off the topic advice. Take some time and thing about the mechanisms of automatic upgrades (think: firewalls, transacted upgrades...) and then build your infrastructure for automatic upgrades FOREVER and SEPARATE IT from your main software. Let the software changes but don't change your upgrade mechanisms. They should be built in a way that provides robust and transacted upgrades (you don't want to end up with corrupted application at 10.000 customers). Allow no actions that could compromise this core infrastructure. You can use .MSI to handle transactions for you and only have small download utility to manage file transfer and run it... Regards, Tomaz
-
I doing HTTP based version checking in the new version of ED4W and I've been surprised and how sites where this doesn't work. I assume that it is being blocked by a firewall or an in some cases personal firewall apps like ZoneAlarm. Certainly from my experience so far you can't assume this will work for all users and at a guess I'm seeing around 50% of sites where it works. I'm only doing a HTTP GET to download a 20 byte plain text file. I can't see any reason why you'd want to upload a file to a server and get it to do the comparison for you. As an end user I'd be more suspicious if even a single byte was being sent from my PC. I agree with all the previous comments about how to go about making it optional etc. I'd be most interested to hear of the experiences of others using Internet based version checking with regard to percent of customers where it works/doesn't work. Neville Franks, Author of ED for Windows www.getsoft.com
Some good feedback, thank you. In addition, i'd just like to make a few amendments: The program would not be updating any files to our server, just a single (16 bytes or so) packet containing the version number and product code (by product code, I do not mean any code that is user-unique, but the acronym for the product name, eg: WBA). I can't see anyone finding this suspicious, so long as it is carefully explained in beforehand. Certainly downlaoding a file containing the version number to the users computer would work, but a request would still need to be sent out by the program to get the file, and this would in the long run just waste time and bandwidth, as the whole version check could be performed with just one communication each way. Making it optional is a good idea, and a combination of showing a "
Do not show this message again." dialog, and having a checkbox in the program preferences to turn the checks on and off. And if only 1% of users upgrade using this method it would have been a sucess. If 50% did it would be a remarkable success. (A happy customer is a repeat customer). David Wulff dwulff@battleaxesoftware.com -
I doing HTTP based version checking in the new version of ED4W and I've been surprised and how sites where this doesn't work. I assume that it is being blocked by a firewall or an in some cases personal firewall apps like ZoneAlarm. Certainly from my experience so far you can't assume this will work for all users and at a guess I'm seeing around 50% of sites where it works. I'm only doing a HTTP GET to download a 20 byte plain text file. I can't see any reason why you'd want to upload a file to a server and get it to do the comparison for you. As an end user I'd be more suspicious if even a single byte was being sent from my PC. I agree with all the previous comments about how to go about making it optional etc. I'd be most interested to hear of the experiences of others using Internet based version checking with regard to percent of customers where it works/doesn't work. Neville Franks, Author of ED for Windows www.getsoft.com
as i said we develop for the financial markets ... most of them are firewall city generally ... we have no problems getting through the http port ... any problems we have we simply ask them if they can connect to the web via a browser ... if they can then we work ... if not its an easy test for them to perform. and to david ... i do agree that uploading anything to the server is not necessary ... not doing it allows you to state "we upload nothing" on the product ... which may or may not be a moot point technically but the PR effect on people is very valuable :) --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
In a certain suite of software im working on, we have plans for an “automatic update notification” feature. Basically, at idle times while the app is running, it has a look to see if the user is connected to the Internet. If so, and a check has not been performed that day, a single packet of information will be sent to a secure server containing the products current version and build number, and the three figure acronym we use to name our products (e.g. WBA). Nothing else (no serial number/name/GUID’s/etc) is sent – other than the current IP that is obtained from the connection at the server end. The secure server would then compare the version number for the user’s product against the current versions stored in a database, then return a single packet to the user (and thus the application) stating whether an update is available or not. No data is stored on the server side. The IP address is not cached or recorded in any way. Then the user would be presented with a message on the next application startup to say that an update is available, and ask if they would like to download and install it. We had brainstormed over whether to prompt the user before sending out the ‘is an update available’ packet in lieu of all the paranoid computer users out there, but decided showing this each day would get very tedious to the end user. Currently we have settled for a design whereby the user is shown a message the first time the application runs, stating that the program can optionally check for updates, anonymously, and would they like to disable this feature. Do you think this approach would be acceptable? Do you think the message needs to be shown the first time the program runs (I say this as many beginner to intermediate computer users may just choose to disable it without realising it actually performs a necessary task.) Do you have any other views or opinions you’d like to share? Yours, David Wulff dwulff@battleaxesoftware.com
I have written an Internet/Client-Server application. When the user first logs on, I check for any updated client programs that user is lacking. If there are updates, they are sent. If the client software doesn't get updated, it probably won't work with the server. BTW. I based this on the way AOL operated the last time I looked.