I was with you up to here:

Now, I'm just want to remember to NEVER borrow your phone :)

OTOH, what you've described is basically what corporate IT security has been about for years. It can be effective, but it's a bitch to maintain is will generally be discarded or circumvented in the name of 'convenience' the first time there is a trade-off between security and a shiny new feature.

My first thoughts, probably like many, were along the lines of "don't connect the TV to the Internet", but that is increasingly impractical as the article points out. Even more so, I can see why I might WANT my next smoke/CO detector, for example, to be connected and able to call the fire department if necessary. It might even be good if it had a mic/camera to allow the firemen to see/hear what is going on -- after all, if they take a look and see me standing there with a pole trying to jab the 'quiet' button and yelling 'false alarm!', they can avoid an expensive and time-wasting truck roll. Or, if they see smoke and people passed out on the floor, they can get it in gear KNOWING that there are lives on the line.

Basically, in short order we will (almost) all have bugged our own homes/cars/offices for perfectly good reasons. Or, if not for good reasons, than as a condition of our fire/casualty insurance policies.

Which means, unfortunately, that any technical fixes are attacking the wrong problem. What we need are behavioral/legislative fixes to make inappropriate access to these surveillance systems prohibited and punishable with real teeth. Punishments that breach the corporate veil, and are stricter in cases of official abuse than for 'ordinary hackers'. I wouldn't commence holding my breath for those laws, if I were you.

At any rate, go vote next week, and vote for 'less bad'. It's the best we can do.

Does this mean that DeWitt clauses (http://sqlmag.com/sql-server/devils-dewitt-clause) prohibiting publication of benchmark results are now invalid by statute in California? I'm sure that would be he very definition of 'unintended consequence', but I'd love for it to be true.

As an admin/IT manager, what I'd like to see is:

1. Meaningful, specific error/log messages when something goes wrong.
2. Accurate documentation of what those errors mean.

Most end-users won't read long or complicated documentation, business application in particular almost always require end-user training on how to use them --as implemented-- and --in accord with company practice/policy--, so generic docs are of limited value.

On the other hand, I sincerely miss the days when I could actually expect proper error codes and documentation thereof, and having that available would certainly influence a purchasing decision on my part.

Once you intentionally circumvent the security of the 'walled garden', I don't think you get to complain about vulnerabilities anymore.

To go with the ever-popular car analogy:

If a guy with a screwdriver is able to start my unmodified car without the smart-key being present, that is a security flaw.

If I modify my car to bypass the 'smart-key is present' requirement to start it, I don't get to complain when my car is stolen by some guy with a screwdriver.

OK, I've done BGP before, and I've never heard of anything smaller than a /24 being globally advertised -- most common router configurations won't even accept anything smaller.

That said, how is any network of any size supposed to protect itself again ISP outages other than multihoming? It clutters the routing table, but there is no other solution.

Well, yes, that actually IS a better idea.

OTOH, if an IP-connected hot-water heater is the only kind on the market next time I need a new one, I'd prefer to have the 'securing it' worked out in advance, because I'm sure not going to do without.

I can't ever see secure firmware becoming the norm given the economics of consumer goods, so I think we're going to need much better firewalls than what we see in SOHO routers currently.

Port/address level control is spectacularly insufficient when everything runs on port 80, and nobody is going to spend time mapping out specific source/destination pairs for everything (The washer can talk to the dryer. The washer can talk to my smartphone. The dryer can talk to my smartphone...)

I'd like to see something like a home-PKCS standard where:
1. Any IOT device requires a client certificate supplied by the router
2. The router drops any traffic not signed by a recognized client certificate
3. The router's signing key must be kept on a seperate USB drive, and the WAN port is locked out if the USB drive is inserted.

To set up a new device on your home network you would:

1. Insert USB key into the router (WAN port shuts down)
2. Generate a new client certificate for the new device (push button "a")
3. Install the certificate on the new device (push button "b" on router and also on device within 60 seconds, enter PIN, something automated like that)
4. Remove USB key from router (WAN port comes back up)

The router will now pass signed traffic to/from your new device. Traffic not signed? No talking to IOT devices for you.

Yeah, key management sucks, but I bet it could be fairly easily automated for home use. It would take more thought and detail than I've outlined above, but should be doable. Unfortunately, that would require that everyone agree to follow the same standard for home-PKCS, and I can't see that happening either.

Plus cheap devices would have the crypto implemented badly, plus you wouldn't be able to turn on the microwave from your office, so on and so forth.

Never mind, I give up.

If I read correctly:

1. Versata produced software 'DCM' incorporating Ximpleware's GPLv2 licensed code.
2. Versata licensed DCM to Ameriprise, who then distributed copies to it's independent contractors.
3. Ximpleware's code is subject to patent claims in the USA, making distribution under GPLv2 impermissible, and Versata did not have a commercial license, making Versata's distribution of Ximpleware's code unlicensed (in the USA).
4. Ameriprise was not aware of (1) or (2) until discovery related to a lawsuit between Versata and Ameriprise.

If this is correct, I can see where Ximpleware has a copyright claim against Versata, but I don't see where Ximpleware has a copyright claim against Ameriprise for any distribution of DCM to it's contractors. Strictly speaking, I suppose Ameriprise did distribute copies of Ximpleware's code, but if they did so under good-faith belief that they had appropriately licensed DCM from Versata, I can not see it being reasonable to hold Ameriprise liable.

At the risk of a possible bad analogy, if Google included undocumented unlicensed code in Android, I would not consider it reasonable to hold each phone vendor liable for infringement, either.

I've got an S2RT also, and I have to agree with you. For me, the worst part is that when it's working well, it's absolutely brilliant. I'd go so far as to say that 95% of the time, it's everything I hoped it would be, and the other 5% it leaves me jaw-droppingly stunned at how fundamentally broken it is.

My two favorite bits 'o broken:

1. The screen periodically gets stuck in landscape, and nothing but a reboot will unstick it.
2. Three times now Bitlocker (which can not be turned off) has decided that it has the wrong key and will not even accept a recovery key. Time to factory-reset.

Both pure software brokenness.

Have you ever tried to keep up with constitutes a "catch" in the NFL? Rules change all the time in pro sports, and players need to keep up. There may be good reasons why pro videogame players are locked to a particular game, but I doubt rule changes have much to do with it.

More likely, in my opinion, is that pro games excel at the game they first learned deeply enough to play "intuitively", and trying to switch is like trying to switch to another language. Do-able, sure, but requiring a long period of immersion to "speak like a native".

With any encryption scheme, key management is usually the biggest pain in the ass. No doubt, this is the biggest problem with implementing encryption for webmail.

Keeping my private key on a USB drive on my keychain could ALMOST work, in that on any desktop or laptop I could insert it to get to the key. For mobile, I think Yahoo will need to release a mail app that supports an easy & secure way to load your key.

Also - keying a passphrase on a moble device to open/sign/encrypt email will suck big time. This could be a great use for a fingerprint sensor on phones.

As neither a farmer nor a marine biologist, I should probably shut up, but hey, this is Slashdot!

I have to wonder how much use of synthetic fertilizer could be reduced by systematic crop rotation between corn and legumes to fix nitrogen naturally rather than dumping on the land? I suppose the price would probably be yields down/food prices up, but food is historically cheap at the moment.

I've been in the IT infrastructure business for years, and have always relied on physical destruction (shredding) of hard drives when disposing of old systems.

I can see where that may not be cost effective with leased systems, but I would take your experience as a warning to clean up after yourself and secure-wipe hard drives when your lease is up and not count on the datacenter to do it for you.

IANAL, but I also wonder who owns the data on a leased hard drive when the lease is up? If you improve an apartment or build a building on leased land, those improvements typically become the property of the owner when the lease is up. I wonder if that has been addressed with data in the absence of relevant contractual language?

It would be interesting to know if an unlocked AT&T phone moved to T-mobile's network suddenly lasts longer.