I don't want to defend Cisco's laziness here, but there is a sort of logic to what they do - especially given all the VAR's that end up deploying these systems: the hardware / software is shipped so that it's easiest to deploy out of the box. A phone installation can go wrong in so many different places, it helps in troubleshooting and remote management to have everything open by default, and then start locking things down once it's running. This approach has obvious flaws, but the alternative would be a nightmare to deploy.

Given this situation, I think customers and VAR's need to be more conscious about security. Maybe Cisco could audit their VAR's to see how good they are at implementing the lock-down checklist. Or maybe they could provide such a checklist directly to the end customer.

Relevant, recent:

http://www.reddit.com/r/Foodforthought/comments/gsp7o/where_does_good_come_from_edward_o_wilson_tries/

Seriously: can someone explain wtf a "Samuel L. Jackson-esque wallet" is? I know who Mr. Jackson is, and I know what a a wallet is, but I'm clearly missing something here.

Explosion detection is pretty cool, and useful I'm sure. But I was hoping for special ops commandos.

My desktop is by no means new (dual core 1.6GHz, 3Gb ram), but running nothing but Debian stable with gnome as my desktop and Iceweasel open with a single tab containing this new homepage: I walked away for 5 min, came back and my 5 min load avg is 0.87.

I decided to do this test after my first, accidental, exposure to this new site design: I innocently opened /. in a tab and had to force quit Iceweasel and close down vmware. I guess my choice now is, I can do all the things I've grown accustomed to doing on this computer, or I can read slashdot.

Seriously, /. - WTF?

Perhaps one solution to consider would be the ability to put the device into a state where nothing but the phone is running - i.e. all other apps are just blocked until the call is released. Alternatively, the phone data in / out could be sandboxed from the rest of the OS. This would be a special mode since there are legitimate uses for this (tone dialing, call recording, etc.), but should be available to switch on when needed (or take the reverse approach and have it on by default, switched off when desired).

I'm not sure if the Android API would allow building an app for this, or if something at a lower-level would be required.... Anyway, feel free to implement this and send me the royalty cheques if you can. Just google for my banking info.

Article: "People have been known to cut themselves when using these really sharp knives. Maybe they should have additional safety features."

You: "Yeah, but those knives wouldn't even get through the door of the prison I live in. Why doesn't everybody just live in a prison like me?"

While "Hardware Controls" seems intuitive for the stated purpose, "Read Phone State and Identity" is fairly common, too. Almost every application will do things differently - whether operating in the foreground or background - depending on whether you are using the phone at the time. E.g. whether to play a sound or ring an alarm. This is one permission I (and I hate to admit it) would barely think twice before granting to just about any app.

On edit, I have to add that I think another factor here is that the w3c purist types see JS as a core web technology, and a better choice for implementing a feature (e.g. animation) than, say Flash (or, worse, an ActiveX control). As CSS and libraries such as JQuery mature, there is a tendency to do things that way rather than relying on an external plugin to execute some functionality. The more this happens, especially in a multi-tabbed browser world, the more JS engine performance counts.

YOU might not want to do FFT in your browser, but there are a lot of companies / coders building websites that want you to. I couldn't tell whether AC was joking about the "cloudscope space is universal" (did AC mean "cloudscape"?), but there's something there. I don't like it either, but ever since Web 2.0 got rolling, the effort has been to offload processing from servers while centralizing control of the data. It's part of the new way, brother.

Would there be a benefit to putting the fastest computer in the fastest train?

Hmmm.... if the train was going fast enough for relativistic effects to kick in, then this would make the computer *even faster*. You, sir / ma'am, are brilliant!

Thread over. We have a winner. OP said s/he wasn't interested in 3d gfx, so the matter is settled. :D

Yes, but if we're going to parse the words that closely, I'll jump in on the side of the OP. Perhaps it's true to say, strictly speaking, that the WAP itself is "unsecured". But if the WAP is unsecured by design (i.e. the design of the *network*), than I'd say it's inaccurate to say that "the network is unsecured".

I leave my AP open to the public on purpose. I have no less fear of an attack on one of the machines hosted on that network through the wireless interface on the router than I do through the WAN interface. The only part of the network that would be "unsecured" due to the AP being open would be a box (ahem, windows) that was connected to it without my knowledge and is listening for connections.

Oh, what? MitM attacks? Puh-lease. Again, the network is no less secure through the open WAP than it is through the WAN interface.

I wish I could give mod points to whoever tagged this story "tuttle". That was the first thought that popped into my head. If you're on /. you should already know, but for the youngun's out there:

http://www.imdb.com/title/tt0088846/

As a sysadmin, the points about maintenance and downtime really resonate with me. And then there's crap like having a team of 10 to 20 staff (many of them very senior) standing around scratching themselves due to some bug or shortcoming (often just in the UI) that would've taken an hour or two to implement. The cost of *not* writing software can be astronomical. As a more concrete example, I worked in a shop that used LDAP to authenticate a myriad of services (desktop signon, shared volumes, shell access, web applications, mail, etc.), but there were some "glitches" in the LDAP schema and the clients weren't always properly configured to use them anyway. Fixing the issue completely would've taken maybe 30 hours. Writing our own web app to create/modify accounts with a step-by-step set of screens that implemented our business logic for new accounts might've taken 150 hours. But doing something like that would be too costly. Better to eat up an average of 5 hours per week of sysadmins time diagnosing trouble with sign-in to individual services, another 5 hours of the staff's time who were trying to sign in, and the occasional 5-10 hour patch of yak shaving when someone stumbled into the thicket accidentally once a month. And on top of *that* are all the dirty little secrets of employee behaviour to work around the shortcomings of the system.