1. Client hits /support/client-info which generates a specific system error with a unique ID (right 6 digits of a GUID) and pumps browser, error and user context information via log4net into our logging system. Client tells us the error ID.
2. Open monitoring system, type error ID in. It's all there.
Not only that, we use it for error monitoring too.
Thinking about it offhand using some Rails terminology, let's see.
* Naive version: save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic.
* Slightly less naive version: check to see if current_user.browser_info has changed compared to the current request in an after_filter or other hook. If so, save it in the DB. This way you can not only check what they're using right now, but what they were doing yesterday when they did something that caused your site to go haywire.
* I'm sure the above can be improved on: it'd be nice to package it up as a gem. This is not rocket science.
Looking in the logs is easy enough, but it's data that should be very easily available to support people, and they probably should not have ssh access to the server...
Probably really wouldn't be that slow, unless done really naively - much of that information is already being written to a web server logfile in most cases, and that doesn't slow things down too much. Send the info to a separate logging server/db. If you're getting a lot of traffic, you're possibly doing a lot of queries anyway - one more is incrementally painful, but shouldn't be a killer.
We only care if there is a system error, if the user phones up or they fill in the online support form. This is only to satisfy the path of the phone call. Everything else is passed around with context.
For the phone call, our logging system has a web interface (log4net appender -> postgres -> asp.net web forms page). you just visit a web page and copy and type the error ID in and you get everything from the entire context, session and client info to the stack dump.
So is having a user read stuff over the phone that you already know.
Plus, I have yet to see the feature that requires coding once and never needs touching again. When I upgraded my app from Rails 2 to Rails 3, there were all sorts of 1-offs like this that I had to tweak and fiddle to get working right again. It takes well over an hour just to remember what you were thinking when you originally wrote it.
It actually took 47 minutes looking at my work log and if I remember a lot of that was making the error page look nice.
It doesn't add up. sorry.
In the build vs buy debate the time versus money theory rarely applies.
Any anti-virus, content filters, other browsers etc are up to the user to sort out - it's in their contract.