Software that "Phones Home"; good? bad? Evil? What notice does one give? How to?

Question

PHONE HOME

Everybody wants to now and then. ...What about software when it grows up and becomes a mature product? Shouldn't it be an adult and live in its new home quietly? Or, should it show some affection from whence it came?...

I've heard some say they'd rip out from the platters any bits that try and communicate without their say so. I've also noticed a large number of products that now routinely ask for permission to send statistical use information. And there are many levels in between.

I'm sitting on the fence.

There’s a long paragraphs explanation of how this question came to me, but for all our sakes, I wrote then deleted it. Suffice to say, I’m Chief Scientist, an officer of the company and head of our development efforts; this is a really big deal and I’m looking for insight from the programming community as I'm not getting any useful feedback here...

The biggest argument for PHONE HOME is that some involved fear there is likely to be serious attempts to cheat the contract(s) and if the software occasionally phoned home it would help detect cheating (for which there are penalties).

Other pro arguments are that it can provide usage statistics and perhaps detect when updates are appropriate.

The biggest argument against is that it’s offensive.

I also haven’t a clue how I would architect this. Clearly, everything calling home all the time is not going to fly. There are a half dozen major products and some will run 24 X 7 X 365.24 and some will be up and down like a frigen yo-yo, yet some data on all of them would be nice - Local repository?

Then there’s connection strategy – a mail message, while convenient, may be a bad call because it can be more obtrusive (perhaps). Then, a simple TCP ssh call may not be so great, either.

So, how about it? If you’re pro, please tell me why. If you’re against, why also. Examples of "doing it right?" Contractual text you like somewhere - or hate?

Next, IF we decide to do it, how should we do it – how would YOU do it? Why?

Frankly, I’m profoundly torn. I hate such things in general, but as an officer of the company, I have to acknowledge above my own feelings, there’s potentially a lot of money on the table here, and being offended may not be a good argument.

Thanks for your thoughts.

Answer 1

I'm not sure that I would do this if I sold the software and if I did I would certainly give the user a choice over whether to participate, but I can see some real value in having certain types of errors (not common, but rather unexpected ones) report back directly to a bug database. You may need to filter them so that duplicates are discarded, or at least marked as such, based on some signature from the message.

Answer 2

I think it was Dvorak or someone like that that covered this once. I totally agreed with his position. Informed consent is the best way to go.

Shrink wrap software should say clearly on the outside of the box what network ports are required, and this should be extended to include phone home requirements and the type of information gathered.

Other commercial software the same thing. Prominently list during install and in written documentation, in help/about, required ports and type of data transmitted.

I think this should be required by law same as (US) food ingredients lists.

Answer 3

Informed consent, where informed means that the type, frequency and content of the information you'll be sending is told to the client is truly the only reasonable option, else you start closely resembling a malware author. People will find out and will dislike you a lot if you tried to pull it off sneakily. You probably can and should present it as a means to improve the service though, everybody likes software that reports bugs by itself.

This means you cannot rely on this to be your cheat detection mechanism, but, given that there's a lot of money on the table, you may be able to contractually put some random inspections. For instance you could register locally the data you'd otherwise send and go look at it in the inspections. I don't think you are forced to declare you'll be locally registering usage information (IANAL, YMMV, WTF, BBQ)

Answer 4

I would tend to use this in moderation. Any informational activity should be opt-in rather than opt-out (i.e. crash reports, statistics, etc).

For protection of your assets, I think it's fine. Many will tell you that it won't stop cheating, because people can fool it, but it can help. Just don't collect any information in doing so that could be (realistically) deemed an invasion of privacy, and I don't see any problem with it. Also make sure that whatever is being done is honed and tested well enough that it's not going to adversely affect the user experience. i.e. if it fails to connect when trying to phone home, and the software no longer works as a result, that could be a big problem.

Answer 5

"I also haven’t a clue how I would architect this. "

A simple way would be to write an application that gets installed along with every one of your revenue generating apps. It knows how to determine what versions of your software is running and it can be triggered to run periodically or it is called from your other apps, etc.

You need a server that just publishes/provides a map (pairs of data) for a product/platform and a version. Then the business logic of determining if a new version is available is on the client. Alternatively you can keep that logic on the server side (a lot to be said for that) and have the client side app send a request with just the current ver/platform info and a response will be generated whether a new version or patch is recommended.

that's just off the top of my head - a real design is called for especially since you have existing software out there apparently.

As for checking for unauthorized use and for collecting statistics I think those are terrible ideas. Companies get burned by that and many earn bad reputations.

Unless you sell it as a service contract that you are going to monitor the software health, etc and the customer asks for it I would drop it.

Come up with a better way to protect your software.

Answer 6

Pro, with users' consent (or just add it to your contract)... For me it's mostly about the statistics tracking and I'm kinda a data nazi... but it's nice to be able to show the numbers to the boss... You can examine how many people have purchased it versus how many actually use it; how they use it, when, relationships between customer size and contract monetary amount, etc. The bigwigs love their pie charts, and the Devs really need a good idea what areas need improvement.

Another great reason is that your app can be made to submit feedback directly to the Dev team, if there's a small customer base. Else, submit feedback to a panel of filter people who will build reports and send those to the Dev staff. Either way this feature allows you to know exactly what customers want, quickly and easily, without having to create focus groups and assume the Business people are telling you the truth about customer communications.

Not that the Business people ever lie to the software people, nor obfuscate the meaning of something... :)

Answer 7

You mentioned in your comments to someone else that the chief concern is with sub-vendors who want to create their own licenses. If that is the case I would focus any software solution around making them honest. The most important benefit I would see from this solution is that you're not affecting end-users this way, only a reseller in the middle. And if the arrangement is profitable for them, it will be worth to do whatever is necessary to ensure that their activities are above-board.

For example, you create the key generation software and distribute to the resellers. This software could automatically communicate back to your company what licenses were generated and any other related data. If the software can't communicate home, then the keys don't get generated.

Answer 8

Phone=home examples:

Some companies have product activation that requires periodic phoning-home in order to continue working. I think this sounds like what you're talking about. Windows Activation is something like this I believe.

Some companies use an opt-in home-phoning system to track what features you use the most, or how you use a UI, etc.

Still other companies have things like crash reporting (Microsoft takes crash reports that people send them super-seriously, for example) and some (CCNetConfig the latest i've seen) even let you file a bug right there and then.

None of that is spyware or malware.

Answer 9

Applications "phon[ing] home" is a very generic term, mostly used in a rather hysterical way ("iPhone phones home!!", "Microsoft Vista phones home!!")

Any software that checks for updates is "phoning home". I simply do not care if it does this.

Conversely, crapware (adware/spyware/viruses) that submits as much info as possible is a problem.

I suppose it depends on..

• ..what data is sent
• ..if the user is aware of what data is sent

Sparkle (the OS X application update framework) has the ability to send some basic system information while checking for updates.

Almost every application I've seen use Sparkle has an option titled "Send anonymous system information" next to "Check for updates". More importantly, it has a "Show what information is sent" button. The data is sends back is stuff like CPU type (Intel or PPC), mac model (Mabook, Macbook Pro etc), number of CPUs, CPU speed.

That is a great system - most people simply don't care, and it gives the developers are overview of what sort of systems people are using their application on. If you are paranoid about it, you can either disable update-checking, or if you want automatic-updates, tell it to send no information (aside from your IP address, obviously)

Answer 10

To me, the important aspects are:

• Explicit opt-in/opt-out.
• Ensure there's a direct benefit to the user of phoning home (such as updates).
• Actively design your application to expect and be enhanced via such updates.
• Make sure you provide regular updates.
• For users that opt-out, provide a manual means for them to phone home.
• Do it quietly. Logitech's updates really p* me off - they typically throw up a large dialogue once a week telling me that they're about to check for updates, then another telling me that there aren't any (and there never are).
• Make sure the app continues to function properly even if it can't phone home.

Answer 11

Does it benefit the user?

Users can gain many benefits from software calling home. With "manual calls" (i.e. the user chooses a command which makes clear the software will now connect to your server somehow), there is nothing bad at all, and it can e.g. simplify the update process, download samples or addons, show your current newsletter, submit accurate diagnostics and crash information.

Automatic calls need the users consent, and they should not be required for another feature that is obviously technically independent of them. A typical use would be update notifications, but also usage statistics - which is starting in the dabble of benefiting you.

The majority of our users like our products, and they like us. In that scenario, I don't think most would object to a feature that benefits us without harming them.

---

Calling home is not offensive. Calling home to make an extra buck at the cost of the users privacy is.

Answer 12

It really depends on whether you trust your clients, and how much value you get from the effort.

Some people will use your code inappropriately. Doesn't matter what you do - if it's valuable, someone will steal it. These are not lost sales, though, and don't think they are. Spending $1M trying to stop this will simply be $1M with no ROI.

There are clients who will pay for some, but not all, of their usage. Usually, this is an oversight. Once they find their overusage, they'll pay for the extra support. The ability to monitor one's own compliance is valuable both to the client (who wants to avoid legal costs) and to you (as it will result in proper licenses purchased). Spending $1M to enable self-compliance will result in a return on investment (though how much of an ROI will depend on your application, your clientèle, and how much they overuse accidentally). The trouble here is in determining the ROI - it'll be hard to quantify.

Be sure you look at this realistically. Go after money that you can get, don't try chasing pirates whose money you couldn't get anyway. That's just throwing away money that could be spent on improving the product for actual paying customers where you could get some sort of ROI.

Answer 13

Here are some guidelines.

Phone home to check license compliance:

• Only at install time.
• Offer Internet or email option.
• Use a one-way identifier hash.

Phone home to check for updates:

• Only with user permission.
• Use a one-way identifier hash if necessary.

Phone home to log crashes:

• Only with user permission.
• Use a one-way identifier hash if necessary.
• Allow user to view information being passed.

Phone home to pass statistical information:

• Only with user permission.
• Use a one-way identifier hash if necessary.
• Allow user to view information being passed.
• Encrypt the information being passed.