I'm running F12 x64 and I downloaded the Chrome beta. Why hasn't anyone pointed out that the lack of an x64 Gears plugin is rather silly?

ehm, back in my day we called it the Big Kernel Lock. You kids!

now get off my lawn!

That is not true at all. My company (IBM) has both technical and managerial paths. Look up IBM Distinguished Engineer and IBM Fellow in wikipedia when you get some time. Technology companies usually maintain two paths.

Thrown out of a passing aeroplane? Really? Have you tried opening the windows on an aeroplane recently? I suppose someone could have flown over in a bi-plane... but really?

That is just nonsense.

If the customer had used a proper PKI with key recovery/escrow this could have been avoided. The solution is NOT to make weak passwords so that you can crack them when you lose your passphrase. How on earth is this modded informative?!

Why would X have worked on any builds of OpenWRT???

Palm has circumvented the published API for doing this (for god knows what reason). And they've done so by "faking" a USB VENDOR ID.

Why not just used the published method as BlackBerry / RIM does?

Last post on this topic - clearly you and I have a different understanding of security. No HTTP POST/GET variable are typed - you can throw whatever you want in them. Lazy assumptions about length won't help you either. Point is, there is an extra set of data to parse. Whenever there is data to parse, there is the potential for an exploit. See my solution above, and lets move on.

Any input taken should be scrutinized for injection, overflows etc. Another input from "out there" another set of variable to scrub. A sloppily coded hash/verification could be a vector for SQL injection for example.

If you have a session to begin with... just store it server side

assumptions regarding the scope, confidentiality, integrity or availability requirements weren't part of my answer. Only that from a security perspective, anytime you have another piece of information that's user submitted, requires a thorough check/scrub/sanitization prior to being processed.

Storing the hash of the original data client side is bad from a security perspective. A malicious user could manipulate the hash as they sought fit. I'd keep the hash in a server side session specific variable. I realize the damage that could be done seems small, but I wouldn't trust *anything* - especially a critical part of your locking mechanism - to a variable that could be manipulated client side.

Are you part of the security team? If not, perhaps this is more the domain of your security guys than yourself. I'd also get the buy in of HR. As with most policy changes (especially ones with a reprimand) you gotta make sure HR is on side. Legal for good measure too - ie are you asking something which is illegal of the employee? I know its a stretch, but CYA.

IBM more heavily embraces Chrome and Mozilla internally than Opera. And Lenovo's preload has nothing to do with the image that IBM uses internally, save the drivers.

I can assure you that IBM (and Lotus as a result) do have a provision surrounding this.

So the OPEN SOURCE community will benefit from BINARY diffs.

uhuh. I think we're just fine with patch/diff.

oh, what's that? You meant the people that DISTRIBUTE BINARY version of OPEN SOURCE programs will benefit? Ahhh, now I see.

If you stayed in real mode