I would prefer to use Firefox w/ NoScript for surfing less trusted sites, and Chrome for known legit sites. Given the recent work on CSRF type attacks, it's probably a good idea to do your banking and shopping in a different browser than you do riskier stuff.

I actually find that my best work happens when I've helped get organizations from the fire fighting mentality to the proactive maintenance mentality. Every place that's gotten fixed I've left because it wasn't engaging any more. I think that even if we as a profession have reached a consensus about how things should generally work, doesn't mean we're all at our best in that mature, well run organization. Some guys are one good as the lone IT guy, or on a small team, some are only good in a well structured environment, and people like me are at their best untangling the mess.

Have you looked at releasing your in house app?

For some things that might be possible, it might even be cool if that mechanic were used with a motion controller. I think that it might be harder to come up with a good way to quantify high skill in non-melee classes though.

Having been a dedicated healer in a few MMOs, the skill lies in resource management at least as much as just keeping people up. Letting a tank get down to 10% health (assuming it wasn't a 1 hit) is a sign of failure, running out of power is a sign of failure, in a bad situation, wasting power on healing the wrong guy is a sign of failure.

The AC has a very good list, I'll see if I can add anything to it.

Network diagrams should be at a network, physical and datalink layers. Only the simplest networks can have all this information on a single diagram and have it be useful. Seperate the network drawing from the datalink and physical drawings as requred but be sure to leave enough detail to connect the drawings (Visio has a nice linking feature for this). Also keep a spreadsheet or database of assigned networks, IP ranges, and assigned static IPs, including a responsible POC for each entry. Also, a spreadsheet of all infrastructure devices with model and options documented along with firmware versions, and support contract information. All ports should have a description entry for what it connects to, and the project/request/change identifier that created the connection.

System documentation starts with the system name, project, admin, data owner, system specs, OS and application software name/vendor/version information, as well as support contracft information. Then comes backup and recovery procedures. After that you have the build procedure, including all configuration changes, and scripts. Also include any system standards i.e. all sofware added is in /opt or D:, all scheduled scripts send output to admin-report mail list, all tape drives are DLT. Supplement with the afore mentioned RCA documents.

Domain/authentication system documentation should include a description behind the premission model and standard premission and logging settings for all systems related. There should be procedures for credential and access changes that are documented and understood by everyone with administrative privilege. All systems should be build to not share credentials, and imperitive credetials should be in a sealed, tamper evident envelope in a secure location (a safe typlically). Things like root and domain admin passwords can be made by 2 or more people and added to the envelope, so no person can make changes without an audit trail.

Databases should have all the system documentation along with schema information, connection parameters, and roll back procedures. Any configuration made for logging transaction logging should be docuemntated and scripted where possible (anyone who has had to custom roll persistent trace logging for MSSQL databases will empathize).

Logging and managment systems should have procedures for adding new systems and new metrics. Managed systems should be baselined, using system thresholds where possible.

Patching and patch testing should have procedures and deployment schedules (i.e. MS patch Tuesday patches should be full deployed within X days/hours of release, Sun patches will be applied to the dev environment within 24 hours of release and deployed to production after 7 days etc.)

Whenever possible use a central system for this information. A Sharepoint, Zope/Plone, or even a wiki can make the information accessible. If the support folks use the docuemntation, it will be maintained. If nobody uses it, no procedures mandate it, it will die. If you have a change management system that enforces documentation updates then people will use what you've done for years to come.

The point about hoarding is a big one. The amount of address space held by US governement entiies ie huge. I've worked with/in several .gov networks and the address allocation in most can chartiably called ineffecient. There are networks of 25K - 50K hosts that use multiple class B and class C allocations, with everything using routable IP addresses, regardless of need.

IPv6 will create some serious growing pains. We have more 20 years of the world wide web and IPv4 w/VLSM experience as an industry. There's a number of things we take for granted in the conventions, and even the protocols that IPv6 can put into question.

I thought I saw this kind of thing at Blackhat US 2006, as a browser expliot.

The difference is that it's "weaponized" now. We start patching, tracking and working on sigs when an expliot comes out, but the risk level really goes up when the threat is in the wild, and again when the expliot is packaged. I'm actually suprised that it's not a multi-vector threat, using maybe a spam or lured browser propagation. That would give the worm access to the protected interface.

Defecit spending should only be done for things that a) you would be doing anyway, or b) that have long term value. Stimulus money should only go to projects that have a effect on the way .gov does business, like Apache, Sendmail, Bind, Snort, Linux, NMAP, Wireshark and possibly Mozilla, Python, Debian and Postgres. Other efforts like giving money to OVDB to develop as an augmentation of the NVD system, which has a horrible tendancy to not contain enough information, would also be a good investment.

Hostfiles are a point solution, a DHTML pop-in block script works even if the source domain is different, without any further analysis.

I find Flashblock works pretty well for me. I agree about NoScript, but Flashblock is a must have for me.

Check out http://dhtmlpopups.webarticles.org/ for a quick set of examples of these.

It looks like a bit of experimentation could yeild a reasonably reliable greasemonkey script to kill these when not click initated.

Isn't IRC multiplayer notepad?

Dan Kaminsky's Blackhat US 2006 and 2007 talks (as I recall) metioned using techniques similar to this to detect protocol based bandwidth throttling, and used it to detect P2P traffic shaping. I would personlly say that this would work to detect a layer 2 man in the middle attack using something like ettercap. Or as Dan said, to detect some kind of inline intercept box on the network. In order to do that, you'd need to hoave a pretty good idea what the latency nubers should be to start with. In my experience, most networks of any size (1000+ users) couldn't even tell you if every SPAN port on there network was authorized and currently in use, so I don't think this technique is currently viable in industry. In highly controlled networks, like I assume classifed networks are, this may be useful.