I'm not saying that SNMP is the correct mechanism for IoT, just that the state of discovery and interaction between IoT 'things' is so dismal(except where specially handcrafted by the vendor) that SNMP's MIBs look positively advanced by comparison.

Crazy-cheap silicon makes connecting things to networks relatively simple; but it doesn't solve the much more difficult problem of making those things interact in a useful way without either intricate top-down command and control or a ghastly nightmare of emergent oddities and security problems. At present, there appears to be very, very, little headway in making the 'things' that are supposed to be internetworking aware of one another, much less usefully so, with people either rolling their own totally isolated little thing or attempting to be the gatekeeper for all device interaction. It does not inspire confidence.

The trick is that security measures have costs, in time, money, user convenience, etc. and it is considered 'crazy'(in the weak sense of 'not sensible', not the psych-ward sense) to voluntarily impose costs on yourself that are out of proportion to the costs of the expected threat.

There's always something you could be doing more securely; but only sometimes is it worth it.

Speaking of AM radios and software on the victim computer: this classic.

Unfortunately only works on CRTs; but it's a heartwarmingly neat trick.

I'd be curious to know (I'm definitely underinformed, so this is an honest question) whether that tactic has lost some effectiveness over time. The classic monitoring-RF-to-read-CRTs stuff depended on getting an adequately clean copy of the distinctly analog output of the CRT. Now, all signals are fundamentally analog signals; but digital signals are analog signals designed to make guessing the correct value really easy(since there are only two possibilities, rather than an arbitrary number of them); and now more than ever it's a safe guess that sensitive data will be heading over a number of RF-emitting digital busses, from the keyboard to the computer, within the computer, and likely to the monitor as well.

Does the broadband noise still drown out the desired signal sufficiently to prevent reconstruction, or does our increased emphasis on high-speed digital busses (often designed to operate with some amount of error correction in the event of cheap lousy hardware being cheap and lousy) make it more tractable to either unambiguously pick the correct interpretation of a noisy input, or make a number of guesses and use known features of the bus to help eliminate the incorrect ones?

Doesn't FreeBSD run on toasters and have SNMP support? I was pretty sure that it did.

We also have a (general, not universal) willingness to let the market squabble it out for an extended period of time, rather than give a good hard shove in the direction of some implementation. This tendency may be abetted by the fact that early adoption creates incumbents who have a vested interest in stalling as long as possible to milk their legacy investments and first-mover advantage, as in our wonderful market for ISPs.

With the payment card industry, you have a lot of people(all clambering to grab as much of the cut for themselves as they can, and shove as much of the risk onto others as they can) with competing agendas and a desire to have their pet proprietary system gain a foothold so they can extract tolls with it(eg. the incidents where some retailers with functioning NFC POS systems were deliberately disabling them because Apple Pay was a competitor to their 'CurrenC' system, and the ongoing spat between Google and the carrier-backed payment scheme formerly known as ISIS before that became a toxic brand). Nobody actually believes that "USA IS #1!!! Mag stripes RULE!"; but between everyone wanting to control the customer data and processing fees and banks, merchants, and payment processors fighting over risk allocation, it's a bit of a clusterfuck.

Compare to say, the DoD's CAC rollout: CACs still aren't what you'd call a joy to configure(especially on OSX, or in Citrix environments, or other oddball use cases); but the DoD decided that it wanted everyone using smartcards for cryptographic authentication, said that that was how it was going to be, and it was so (relatively) quickly and smoothly.

Opinions vary on how often we dodge a bullet, or get the benefit of something new and innovative, thanks to there being no mandate in place vs. how often we suffer pointless bullshit for an agonizingly long period of time(eg. the less-than-totally-compatible US cellular market); but the fact that we tend not to mandate an end to such fights all that often, or all that quickly, is simply a fact. Even when we do mandate something, it's often a de-facto 'national' mandate created because California, or another large state, demands something and it's cheaper to sell California-spec everywhere than it is to have two SKUs.

Depending on how motivated the thieves are, it may be more cost effective to have some shock-sensitive dye capsules embedded. Since they'd only be breached in the event of an attack(or really serious damage to the ATM from other sources) they could last the life of the machine and be entirely passive. If you were feeling particularly motivated, it would cost only a modest amount extra to get an ink with a unique tagging agent, per ATM, so that marked bills could be traced directly back to a specific attack.

If a lot of ATMs are being blown up, or attackers are unconcerned by dyed bills(maybe because of literal laundering, maybe there are people who don't care?), then active defensive measures are more likely to save enough hardware to be worth the cost. If not, a passive capsule or capsules fragile enough to break during an explosion are simple, low-maintenance, and a fair deterrent.

Pretty much all embedded devices smart enough to support TCP/IP, as well. I'm pretty sure that my router is currently the most 'IoT' device in my house, though also the least conceptually novel.

There are some honestly interesting, tricky, and (at least partially) novel problems in 'IoT'. Making devices that are networked, can talk to each other, and actually do something useful with that ability is a real challenge. Even more so if you want compatibility between multiple vendors, support for use cases the vendor didn't more or less build for you(ideally without requiring that the user be a software engineer), or some semblance of assurance that there aren't a zillion security and privacy issues, innumerable covert channels, and other disasters.

My apathy is mostly derived from the fact that most 'IoT' doesn't actually seem to be doing much of that. Plenty of stuff that lets you use the internet as a very long serial cable to connect to its config interface(which is fine, the internet is a great way, if secured, of very, very, cheaply connecting from arbitrary distance; but brutally non-novel), some walled-garden 'ecosystems' that support very limited interaction of devices between two vendors who have explicitly agreed to cooperate and updated their products to make that possible; but otherwise it's mostly the same old IP-capable firmwares that devices expensive enough to have the capability have used for at least something like two decades. Useful; but not terribly new, and often implemented so badly as to be a liability.

It's honestly a trifle disheartening. While arguably in need of some serious maintenance(especially the 'security' of the earlier versions), SNMP is arguably closer to an 'IoT' design(pretty much just add the ability for devices to advertise their MIBs to other devices on the network, rather than having the admin hunt them down and load them, and you are closer to being ready than most actual products are). That isn't really a flattering thing.

SNMP is quite useful; but it is a bit crufty and conceptually ancient. The fact that everyone's shiny, new, 'IoT' things, with their markedly-more-capable-and-way-cheaper embedded hardware typically can't advertise their capabilities and manipulate one another in some vaguely sane way at the same level as some seriously old hardware is not terribly impressive.

Even if the actual implementation is some XML-soup-and-'cloud'-bullshit horror, conceptual parity or superiority would be nice to see.

I suspect that the mania will be tempered by the fact that it will be fairly easy to classify all sorts of projects, that you were already doing, as "IoT" if you wish to seem super cutting edge and so on without actually making any changes.

There's a vague sort of notion about what "IoT" is supposed to be, cobbled together from some mixture of analogies to SCADA and industrial control systems and science fiction; but it is broad and ill formed enough that all sorts of things that can connect to a network in some way, and any and all software associated with them, can be covered without stretching the truth too hard.

Plus, until the various squabbling factions decide how to actually make the 'things' interact usefully with each other(the current preference seems to be 'appoint either Google or Apple as Feudal Oligarch', with 'don't even bother, everything you buy will have its own terrible app!' as the runner up), the 'internet' bit is really just being used as a convenient remote access to the control panel(and for monetizing users, of course), which is much less hairy and challenging than actual interactions among things in some conveniently configurable and/or emergent-without-being-pathological way.

Any guesses about how many existing 'embedded system that connects to the internet in some fashion' projects were dubbed 'internet of things' in order to bring this new buzzphrase to prominence?

Yeah, yeah, I know, at some point the scale and pervasiveness of embedded connectivity may reach a point where it is different in kind, not just degree, from past use; but I submit that we aren't there yet by a nontrivial margin. For the moment, "IOT" seems to mean 'has a terrible smartphone app' or 'last model, you connected to the serial port to configure the system; when we revised the hardware it turned out that adding ethernet would be cheap and lots of customers wanted it, so we added it.'

I agree that an update to 802.11 would be nice, unauthenticated management frames are a potentially nasty issue; but the rest of the argument is nuts.

All sorts of crimes can be committed by means of a speech act(indeed, many crimes are hard to commit without some means of communicating, fraud, extortion, ransoming hostages, etc.); but that doesn't give them constitutional protection, any more than the argument that your god demands blood sacrifice would provide protection against murder charges.

This is classic Locke stuff: a restriction aimed at restraining speech is illegitimate and illegal; but that does not imply that the mere use of speech to commit a given act necessarily covers that act under the protections given to speech. Same with religions. Restrictions targeted at a given exercise of religion are unacceptable; but this does not protect someone who breaks a law established for suitable unrelated reasons.

There's also the (only partially related) matter that 'radio interference' need not always imply "really loud white noise or other stochastic garbage at the appropriate frequency". That's often the easiest way, and for relatively primitive radio systems that have very few features to exploit it may be the best one; but if RF emissions specifically tailored to cause a radio system to fail aren't 'radio interference', what exactly is? Higher level attacks offer substantial advantages in power requirements, precision targeting, resistance to noise-mitigation mechanisms, and so on; but just because they aren't pure noise doesn't make them not interference.

That seems like a fairly slim bit of legal weasel-wording given that nowhere is "your airspace" in the slices of spectrum that wifi uses. I would certainly agree that 'containment' should only be performed in 'your airspace'; but there is no such space.

In private buildings that don't offer guest services or otherwise accommodate outsiders, you can certainly disconnect anything you don't approve of from the wired LAN, and ask anyone operating a hotspot to leave or be removed for trespassing; but the notion that you enjoy preferential rights to that spectrum by virtue of owning the building is simply unsupported.

Indeed they can. Unfortunately they decided to let the people responsible for ACPI actually follow through on that, and then decided that it would make a good bootloader.

What I find most baffling about the whole affair is how something that one would ordinarily think of as a fairly overtly malicious exploit, spoofing the appropriate management frames to break a network you don't have authenticated access to the configuration interface for, became a 'respectable' tool for 'management', even included out of the box in fancy commercial products from vendors with risk averse legal teams and so on.

This seems like the place where somebody who has been dealing with enterprise wireless gear long enough to have observed the change might be found. Did this 'feature' cross over from what was initially a proof of concept by a security researcher? Was it recognized as a possibility before the standards had even been hammered out and was available from day one? Do we know what vendor adopted it first? Were there any who specifically didn't offer it for legal, rather than technical, reasons?

At this point, it is certainly the case that at least some wireless management consoles adopt a very...possessive...tone, detecting 'rogue' APs, despite those APs being no more or less legitimate than any others, in terms of spectrum use, and offering 'containment' or various similarly clinical euphemisms for dealing with them. How, historically, did it come to be that this nasty DoS trick went all legitimate, even as generalized hacker hysteria can get you a stiff dose of CFAA charges for almost anything that involves a CLI and confuses the DA?

I'd love to have my hands on all the versions of various vendors' wireless management and administration packages, to see how this feature evolved over time. I can certainly see its appeal; but I find it hard to believe that nobody had serious doubts about its legality from time to time.

Less likely. The FCC is pretty clearly within their powers in saying that you aren't allowed to intentionally interfere with other people's Part 15 devices by using your own to generate disruptive RF.

There is no obvious coverage for forbidding the sale of devices having a Part 15 radio component; but lacking a software configuration for providing network access to other devices with that device. They might be able to shove it into the conditions of a spectrum auction, and make it binding on the buyer; but it's more of an FTC problem.