A dumb TV still has a TV tuner, so they aren't equivalent.

But unless you plan on plugging it directly into an antenna for OTA broadcasts, they are basically equivalent.

- TVs don't need anywhere near the same level of display quality. They are viewed from ten feet away and do not render small text, so they don't need as clear a picture. They also don't really have to go over 30fps, and latency is less of a concern. Basically, they have looser constraints in many ways, making them cheaper

- TVs have a plethora of inputs of many formats

- TVs have remote controls

But I doubt you could buy a 60" glass front monitor for the price they sell TVs :)

As long as securities react to hacks, there will be a massive incentive to 1) hack, and 2) overstate the hack's significance. Furthermore, as bots become more sophisticated, confusing them becomes easier. If you know bots will short CompanyX when "CompanyX hacked" hits the headlines, then you have an unfair advantage just by being the first to know of the hack.

It worked OK for a while, but the setup was not robust and eventually some controllers would not work some devices at some times. The annoyance factor in going from 0 errors to a 1% error rate is HUGE.

Five years passed, and I have been slowly replacing all these X-10 devices with hard-wired switches or with Insteon. Of course, the original 1959 wiring paths (12 gauge Cu FTW) still work fine.

Now, when I see connected/automated homes in design mags, all that tech seems more like a long-term maintenance headache than a desirable feature. If I had an unlimited budget, I would not build those features in, I would just install conduit and run old-school copper wires through it.

My lessons: (1) The design life for a home is decades, the refresh rate for home automation devices is years; (2) Upgrading/tinkering is fun the first time -- but only the first time; (3) Your spouse hates it more than you do; (4) The existing device does one thing without fail, replacing it with a device that does more things but sometimes fails is not a net gain.

But prices need to come down, light output needs to go up (wireless bulbs seem to top out around 60W equivalent), and switches need to not be a $60 optional accessory (looking at you, Hue Tap). Controlling lighting with your phone is neat, only being able to control lighting with your phone sucks.

Long term, I'm sure I'll end up with more IoT devices. But it'll be because they got shoved down our throats and I didn't want to pay more to avoid new "features," not because I wanted a wireless microwave.

All you need to do is only run one fiber jumper, the TX from one side to the RX on another, not the two you're "supposed to" use. SNMP traps run on UDP and work just fine, old style syslog runs over one way UDP too. Note that your production/secure network can DDOS your IT/insecure network if enough people on the secure side try to use a DNS or NFS server on the insecure side, it'll just spam packets forever and never get its response, so its not like firewalls are completely pointless.

In the really old days we'd do something similar to RS-232 cables, physically yank out pin 2 or pin 3 (conveniently they swapped TX/RX on 9 pin vs 25 pin RS232). PPP negotiates connections, SLIP doesn't care and works great.

(edited to add another thing we did back when 10 meg ethernet was "new" and just replacing thinnet and thicknet, was pulling the approriate pins for TX, before auto negotiation existed, before 100 meg ethernet even existed, you could get away with that... I suppose if you had two smart-ish switches that could be forced to 10 meg no negotiation, you could do this today...)

Also there were production machines that output error, alert, and log messages to theoretically directly attached parallel port printers and there also existed converters that could go from parallel port to serial port (presumably for serial port printers, which really did exist in the 80s), which makes a pretty good unidirectional connection from a secured device to a semi-secured logging server. Bidirectional parallel ports didn't really exist until maybe 1990 or so and never did standardize, not really.

I made a lot of money implementing this kind of stuff in the 90s. It was fun.

Correct. To simplify, imagine a diode on one side and a photodetector cell on the other. On a microcontroller, this would be an opto-isolator (http://en.wikipedia.org/wiki/Opto-isolator).

Of course, the higher levels of the OSI protocol you're using need to support this sort of physical layer. Its typically used on very primitive, low-bitrate connections (sensors mostly, although I've seen it used in highly sensitive installations using scada equipment).

Bruce Schneier has a great piece on air gaps. I've included a link to it below.

https://www.schneier.com/blog/archives/2013/10/air_gaps.html

Thanks for all the useful responses. I always learn something new by reading the comments :)

Imagine that the designers want to send information about the plane's expected arrival time to the in-flight entertainment system. You could send a packet once per minute, without any knowledge of whether or not anyone is even listening. If an update is missed, it doesn't matter since the information rapidly becomes stale.

It obviously wouldn't work for carrying something like TCP/IP but rather much lower level signaling.

http://en.m.wikipedia.org/wiki/Opto-isolator

Consider an N bit stream of data, with a probability mu of any given bit being flipped. Then the probability of your stream containing an error is gamma := 1-(1-mu)^N. Since you're sending the identical stream twice, there's a 1-(1-gamma)^2 chance that your overall transmission is unrecoverable. The hash will tell you that the transmission failed, but not how to correct it. Furthermore, there's a probability that your hash has a bit flipped somewhere, too...

An error correcting code makes a guarantee that if up to m bits are flipped, the original message can be recovered exactly. A Reed-Solomon code can correct up to m errors while adding just 2m bits to the message length; even with a pretty conservative upper bound on the number of expected errors, this should be way less than 2N+k.

And hell yeah you can prove it's not in there, either with a quick wireless scan or even a simple physical tear down of the housing which can then be put back together.

Show me a dumb TV that has been wired up to spy on people that has been in the wild before.

The cheapest 50" TV they have is $799 has interactivity. http://www.lg.com/us/tvs

An assumption is reasonable if it follows logically from facts we know about the world to some conclusion. For example, cars with more features usually cost more than cars with fewer. A washing machine with a detergent dispenser and 11 different wash modes costs more than one with 3 modes and no dispenser. A thermostat that just sets the temperature and does nothing else will almost always be cheaper than one with wifi connectivity and a companion iOS app.

Based on that knowledge, its reasonable to assume that a TV with more features will cost more than one with fewer. This assumption is wrong of course, but it wasn't unreasonable.

So that means an assumption is unreasonable if there's no reason you'd make it in the first place.

Thanks for confirming my suspicion; the fact that "it's a feature not a bug" is pretty unethical has nothing to do with whether it can successful or not. It's a useful logical tool to learn to distinguish "is" from "ought"; whether or not you think that Smart TVs are better than dumb TVs or not has no bearing on whether or not they're marketed as such and most importantly believed as such by the majority of consumers.

Hell it's not even one of the worst heuristics in play: (higher) price and popularity of a product as a heuristic for quality may be even worse than "more features" as a heuristic, and these two are extremely prevalent. And yet just because I don't like them doesn't mean I pretend that these tendencies simply don't exist.