17

As the Internet is pretty much ubiquitous, can we as developers assume that all users have Internet access? Now I don't mean that the code is written in such a way that if there is no connection then the whole program crashes due to lack of error code. What I mean is, can programs today be developed under the assumption that its users will always have access to the Internet?

You may ask "What do we gain by assuming that?" The reason why I'm asking is because at uni we use quite a few programs which require Internet access due to the way it checks the licenses (it checks your IP address -- if it's not an address at campus, then you you're not allowed to use it). Note that the program itself should work fine without Internet access; it's just needed for license checking.

EDIT: I'm talking about desktop applications here.

EDIT2: From some of the answers I get a feeling of being accused of exploiting the users in unethical ways. I'm not endorsing what I've described in this question -- I'm just asking about it because the developers of some of the programs we use at uni have done this. Personally I think doing this is plain out stupid and wrong.

5
  • 4
    Ideally the license-checking wouldn't even be an issue. Dec 16, 2010 at 23:11
  • 1
    desktop app? mobile app?
    – Marcie
    Dec 16, 2010 at 23:15
  • @Marcie: Ah. I meant desktop applications. Question updated.
    – gablin
    Dec 17, 2010 at 10:48
  • 7
    I may have internet access, but my company firewall might not like my computer talking to your computer :)
    – user131
    Dec 17, 2010 at 10:53
  • Please note that web access isn't Internet Access.
    – MSalters
    Aug 2, 2011 at 11:59

10 Answers 10

43

Bad idea, for three reasons. First off, even though everyone has Internet access these days, which is basically true, they don't always have it available at all times. My primary machine is a laptop, and it's connected a lot of the time, but not when I'm on the bus, for example.

Second, and sort of related to the first, is your method of checking. What if a student gets a legitimate copy of the program, puts it on his laptop computer, and then goes to study with a friend who lives off-campus? You've just introduced a heck of a false-positive condition into your license checking.

Third, there's an ethical problem with the license checking in the first place. If a person chooses to place a program on their computer, you have no right to cause their computer to treat it as invalid. In any other context that's called hacking and it could land you in all sorts of hot water, and just because our copyright laws have been hijacked by copyright owners to make a special-case legal exemption for this scenario, that doesn't make it right.

Enforcing the law is the job of law enforcement, and private individuals are highly discouraged from taking law enforcement into their own hands (vigilantism) because they tend to do it all wrong. (Just look at the Sony rootkit!)

Your best course of action would be to assume that the user has an Internet connection available for features that actually require it, but not require it for features that can get by without it, and certainly don't require it just to convince the program that it's not an illegitimate copy!

3
  • 2
    note to self: vote up when the vote counter resets
    – Inaimathi
    Dec 16, 2010 at 23:20
  • I don't think gablin is actually interested in designing such a system, he's just using that as an example (which my university did, too, with web-based services like JSTOR). I agree with everything you suggest, though. Internet access is indeed not ubiquitous…
    – msanford
    Dec 17, 2010 at 3:08
  • 2
    As msanford just said, I'm absolutely not interested in designing such a system. And I agree completely with your answer -- having to VPN into campus from home just to be able to work on the lab remotely is a pain in the ass! I can't understand what they were thinking when designing such a validation system, and I figured "Maybe they were assuming everyone have access to the Internet". Hence, this question. Again, good answer. +1
    – gablin
    Dec 17, 2010 at 10:52
26
  • Not all users have usable internet access. For example, outside of small and medium cities (and their suburbs) and university towns, the US has almost no broadband infrastructure. Small town and rural users are generally on satellite or dialup (and their phone lines aren't always the best, so dialup is often below 50k/s).

  • Users with good internet access at home/office often operate in other places: parks, airplanes, cafes, conference venues, etc. that usually lack reliable internet access.

  • Many users invest in back-up power for a reason: so they don't experience down time during outages. If you cripple your application when the internet goes down, you've just robbed them of that investment.

  • Internet connections fail, ISPs (or workplaces, or universities) block traffic at their own whim, home users misconfigure their NATs... it is just plain stupid to create an artificial (i.e. not a technical consequence of building the thing) point of failure in your software.

The above reasons alone are more than enough not to use the "call home" DRM model; but even if none of them were true, I'd still advise against it because, as Mason already tried to point out, it is ethically wrong to exploit your users in this way.

You don't get to expose information about your users just for the sake of your own piece of mind. You have no right to monitor when and from where they use your software. Doing this sort of thing violates your users' trust.

1
  • 7
    +1 for "creating an artificial point of failure." That's a very good way to describe it. Dec 17, 2010 at 0:20
16

No!

All programs should consider access to the internet to be a best-case scenario, with a fallback mode for when the computer may not be connected.

With so many laptops out there, and with the nature of most public wireless networks to still be pay-for-use, most laptop users are going to regularly experience conditions where they need to use their computer and their programs without a connection to the internet.

As other answers have also posted, it's safe to assume that the computer will be connected at some point in the future. Many synchronization-type apps that have an offline mode work this way. But, as a matter of courtesy to users, don't operate this way unless it is a service to the user. I don't think license-checking falls into that category.

15

No

you can not assume all users have internet access. For basic Stats click here

Excluding web applications, a desktop application should not assume in my mind that it has internet access.

4
  • 1
    I like the fact that you included statistics in your answer. Way to give tangible evidence.
    – lazyPower
    Dec 17, 2010 at 4:27
  • 1
    unless it's a browser (although even that is changing with HTML5). Dec 17, 2010 at 7:03
  • 2
    Yes, but even a browser can be used off-line :) There are many a legitimate situations where this could be used. For example in .NET a "web browser" control can be embedded in forms. This allows a desktop application to create HTML (eg reports) and have them displayed within the embedded form, the HTML file is either passed in memory (loaded from a string) or read from the hard drive.
    – Darknight
    Dec 17, 2010 at 12:15
  • Even web apps could be purely intranet-based and the users possibly have no internet access whatsoever.
    – MartW
    Dec 17, 2010 at 13:47
6

The short version is NO, you can't assume all users have internet access. As others have mentioned there are a large number of people with limited or no internet access at home.

Your licensing scheme should be able to handle the case that the computer the software will run on will never have access to the internet. It is not all that unusual for corporations to have networks that are isolated from the internet (especially when dealing with security concerns). This is especially true if you will ever want to be able to sell you software to a government agency. The other side is how will you handle updates? If you will want to sell to corporations/government you will have to support Enterprise rollout of the updates.

4

Yes in the sense that most people who work with computers can access an internet connection (so it's probably ok to distribute bug fixes through a package manager or FTP or similar).

No in the sense that most people don't necessarily have consistent, reliable, performant access to the internet all day (so assuming that each of your users can pull down 20mb/s consistently is probably a bad idea. People do also periodically use buses and airplanes where you're pretty much guaranteed a lack of connectivity).

2

I think it's reasonable to assume that all users will have internet access most of the time, or at least at install time. However, if I take my laptop with me on a plane, to a cabin in the woods, or on a boat out at sea, I would expect anything that doesn't obviously require internet access to work fine.

1
  • 3
    Actually, net access at install time is a bad assumption. It's not always possible or permissible to connect the machine where software needs to be run to the internet, so it's important to allow someone to download the necessary files with a different machine and then manually transfer them to the machine where they are to be installed. Dec 17, 2010 at 7:50
1

The answer is of course, it depends. If you are building software for a factory floor there is a good chance they wont have internet access. For consumer applications they most likely will.

1

It may not be desirable to have an internet connection, like in the case of users who use my Pawnshop Management System (an RDBMS-based desktop app). They just dont trust having the internet connected to the same computer which holds all their customers personnal information and the pawnshops transactions. If they want to access the web, they use a separate computer which does not have any personal info on it!

0

Floating licensing server is a similar concept. I used a compiler on IBM's AIX, which constantly checked against a licensing server. It thus was slow and we finally ported the code to gcc.

It's fragile and annoying. I think it only makes sense for very expensive software by almost-monopolistic companies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.