First of all, I don't really think people have any greater motivation "to upgrade Windows/Mac versions": Here are the usage share of web client operating systems (August 2010): Windows XP (48.32%), Windows 7 (19.81%), Windows Vista (18.43%), Mac OS X (6.42%), iOS (iPhone) (1.40%), Linux (1.34%). So nearly 50% are using an outdated OS (XP).
By contrast, here are the usage share statistics for browsers: Overall- IE (31.1 %), FF (45.1%), Chrome (17.3%), Safari (3.7%), Opera (2.2%). Breaking down IE by version- IE9 (0.2%), IE8 (17.3%), IE 7 (8.0 %), IE6 (5.6%). And for Firefox- FF4 (0.8%), FF3.6 (35.3%), FF3.5 (5.6%), FF3.0 (2.9%). So over 50% use the latest stable (or beta) versions of these browsers.
As for your other question--"How can you tell your end users that they will need to upgrade their browser to use the latest version of your website without a huge outcry?"--you must understand (i) the factors motivating people to upgrade, and (ii) the factors inhibiting people from upgrading; then you must use these factors to bolster your appeal to your end-users.
Motivators
What rewards do end-users get by upgrading? Skimming Microsoft's IE8 marketing materials, these are the motivators they stressed most:
- Appeals to Efficiency/Laziness:
- Faster surfing (i.e., you will gain more free-time if you switch)
- You can accomplish more work with fewer clicks, because of a more intuitive design. IE7 had put certain buttons in strange places, etc. (I.e., you will lose less effort [as measured in clicks] if you upgrade).
- Appeals to Security/Fear:
- SmartScreen protects you from malicious software (i.e., you will lose safety if you don't upgrade).
- Compatibility View allows you to view older pages correctly just as the website’s designers intended (i.e., you won't lose anything if you upgrade).
So motivators boil down to what the end-user will gain by upgrading (or lose if they don't upgrade). These things must be important to the end-user: Time, effort, financial security, compatibility, etc.
Reinforcers
Reinforcers aren't rewards, but they help increase the rate of adopting the desired behavior. Here's an example: Your web site can detect old versions of browsers, and direct users to download and install the latest versions by providing links and motivators.
Inhibitors
- Nuisance (cost in terms of time and effort) to upgrade
- Nuisance of learning something new
- New versions are inevitably buggy and suffer from incompatibilities that haven't yet been discovered
You must anticipate these arguments, and develop effective counter-arguments:
- There is a risk/reward trade-off, and the rewards outweigh these risks.
- New versions of browsers are fully supported, and bugs will be worked out. By contrast, older versions aren't well supported; and the oldest version have lost support entirely.
There's a general misconception (and misuse) associated with 403 Forbidden
: it's not supposed to give anything away about what the server thinks about the request. It's specifically designed to say,
I get what you're requesting, but I'm not going handle the request, no matter what you try. So stop trying.
Any UA or client should interpret that to mean that the request will never work, and respond appropriately.
This has implications for clients handling requests on behalf of users: if a user isn't logged in, or mistypes, the client handling the request should reply, "I'm sorry, but I can't do anything" after the first time it gets the 403
and stop handling future requests. Obviously, if you want a user to still be able to request access to their personal information after a failure, this is a user-hostile behavior.
403
is in contrast to 401 Authorization Required
, which does give away that the server will handle the request as long as you pass the correct credentials. This is usually what people think about when they hear 403
.
It's also in contrast with 404 Page Not Found
which, as others pointed out, is designed not only to say "I can't find that page" but to suggest to the client that the server makes no claims of success or failure for future requests.
With 401
and 404
, the server doesn't say anything to the client or UA about how they should proceed: they can keep trying in hopes of getting a different response.
So 404
is the appropriate way to handle a page you don't want to show to everyone, but don't want to give away anything about why you won't show it in certain situations.
Of course, this assumes the client making the request cares for petty RFC flippancy. A malicious enough client isn't going to care about the status code returned except in an incidental manner. One will know it's a hidden user page (or a potential hidden user page) by comparing it to other, known user pages.
That is, let's say your handler is users/*
. If I know users/foo
, users/bar
and users/baaz
work, the server returning a 401
, 403
, or 404
for users/quux
doesn't mean I'm not going to try it, especially if I have reason to believe there is a quux
user. A standard example scenario is Facebook: my profile is private, but my comments on public profiles are not. A malicious client knows I exist even if you return 404
on my profile page.
So status codes aren't for the malicious use cases, they're for the clients playing by the rules. And for those clients, a 401
or a 404
request is most appropriate.
Best Answer
These checks invariably fail. Try to avoid tying your application to specific software, browsers or versions. Code to standards. As it appears you are Microsoft based, you may need to code around issues with different Internet Explorer versions. Try to keep these to a minimum.
From a security standpoint, you don't want to prevent users from upgrading to a supported version. You especially don't want to force them to remain on an insecure version.
I have run into numerous issues with built-in checks. Two significant version checks (both from vendors that should know better) I have had to deal with are: