The Internet of Things might have less Internet than we thought?
Machine learning is traditionally associated with heavy duty, power-hungry, processors. It’s something done on big servers. Even if the sensors, cameras, and microphones, taking the data are themselves local, the compute that controls them is far away. The processes that make decisions are all in the cloud.
But this is now changing, and that change is happening remarkably quickly and for a whole bunch of different reasons.
The Internet of Things Might Have Less Internet Than We Thought?
Alasdair Allan looks at the possible implications of machine learning on the edge around privacy and security. The…
The nature of what we do as developers means that we often obsess about now and next, rather than taking the time to put things into proper historical context, and I think that’s a mistake.
So every once in a while it’s worth it to take a step back, and look at history, then decide whether we want to repeat our mistakes, and our triumphs, just one more time, or whether we should be doing something different this time around?
Because we’ve been here before, back in 2011. It was, by any measure, the dawn of the Big Data era. There were new tools appearing, new levers to move the world, we all got a rather excited.
However at the endless succession of big data conferences that followed I mostly didn’t talk about big data. Instead I talked about machine learning, and small data. Distributed data.
Nobody was all that excited about Machine Learning back then, it’s funny how things turn out. Because almost a decade later it turns out that the machine learning and small data systems might well be about to take over.
Now for anyone that’s been around a while this isn’t going to be a surprise, as throughout the history of the industry, depending on the state of our technology, we seem to oscillate between thin- and thick- client architectures.
Either the bulk of our compute power and storage is hidden away in racks of sometimes distant servers, or alternatively, it’s in a mass of distributed systems much closer to home. We’re now on the swing back, towards distributed systems once again, or at least a hybrid between the two.
Because machine learning has a rather nice split, that can be made, between development, and deployment. Initially an algorithm is trained on a large set of sample data, that’s generally going to need a fast powerful machine or cluster, but then that trained network is deployed into an application that needs to interpret real data in real time, and that’s a much easier fit for lower powered distributed systems. Sure enough this deployment, or “inference,” stage is where we’re seeing the shift to local (or “edge”) processing right now.
Which is a good thing. Because let us be totally honest with ourselves, as an industry we have failed to bring the people along with us as we’ve moved to the cloud. We have engineered increasingly intricate data collection, storage, and correlation systems. We have lakes, and silos, and it doesn’t matter because outside of this room, this conference, and this industry, our industry, is universally viewed as a trash fire.
A McKinsey survey last year asked CxO level executives if their company had achieved a positive return with their big data projects. Just 7% answered “Yes!” and that’s not even the real problem with our industry right now. We have much more serious problems that “…our stuff doesn’t actually add any value to your business.”
More than a few years ago now Mark Zuckerberg famously stated that privacy should no longer be considered “…a social norm.” Zuckerberg was right, and it became the mantra of the big data era. But we’ve been hearing “privacy is dead” for well over a decade now, and as long as people still feel the need to declare it, it’s not going to be true, and there is now a serious privacy backlash happening.
I really don’t think the current age — where privacy can no longer be assumed, it’s not the social norm — is going to survive machine learning, or the internet of things.
Built by a team from the Human Computer Interaction group at the University of Chicago the “Bracelet of Silence” uses ultra-sonic white noise to jam microphones in the user’s surroundings.
This is hardly the first privacy wearable, but it’s probably the most commercial I’ve come across at this point.
The prototype is large and bulky. But there really isn’t anything here that would force a mass produced model to be so large. A commercial model made for the mass market would be smaller, sleeker, and would probably retail less than twenty dollars.
Privacy is not dead, it just went away for a while.
The last decade can be summed up by the question, “…you’re being watched. Are you okay with that?” Although realistically we didn’t give anyone a choice.
As our new tools, those new levers on the world, came into widespread use over the last decade, we’ve seen an increasingly aggressive and rapid erosion of our privacy. Because privacy isn’t really about keeping things private, its about choice. The choice of what you tell people about yourself.
That really annoyed the European Union.
Of course, we’re doing it again in response to the GDPR.
Technological fixes rather than cultural ones.
Because the GDPR is actually pretty simple if you decide you want to abide by the spirt of the law, rather than trying to find technological or legal loop holes around or through it.
Although its arrival did create a whole “GDPR compliance” industry that, for the most part, is just snake oil. To be entirely clear. To imply that someone is hawking snake oil is to not only call their product low-quality garbage, it implies that they are knowingly defrauding customers to sell them junk.
But none the less the arrival of the GDPR in Europe, and to a lesser extent the CPPA in California, is just a symptom, not a cause of the recent rise in debates around privacy. A reaction to our own industry’s failings.
This is an actual screenshot, from an actual app, controlling actual “smart” light bulbs.
Just like many US websites, this particular lightbulb stopped their service after the GDPR came into force.
Which makes you wonder what data, about when, and what, bulbs you’re turning on or off is the company behind the app selling on, or using in ways you don’t expect.
To be clear, I’m fairly sure this sort of response isn’t legal under the GDPR.
You can’t refuse to provide the service just because the user refuses to let you have their data, unless that data is required to provide the service, and I can’t conceive of a case where GDPR infringing data is necessary to turn light bulbs on or off.
A series of almost accidental decisions and circumstances have led to a world where most things on the web appear to be “free.” That doesn’t mean they are free, just that we pay for them in other ways.
Our data and our attention are the currency we use to pay Google for our searches, and Facebook for keeping us in touch with our friends.
Whether you view that as a problem, is a personal choice. But it was, perhaps not unanticipated. With no idea of the web, which was still years in the future, the people building the Internet did think about the possibility.
This from Alan Kay,
who in 1972 anticipated the black rectangle of glass and brushed aluminium that lives in all of our pockets today, and the ubiquity of ad blocking software we need to make the mobile web even a little bit useable.
But wAlan Kay’s prediction of the existence of the smartphone was almost prophetic, it was also in a way naive. It was a simpler time, without the ubiquitous panopticon of the modern world, without the security threats, which arguably shapes the modern Internet, and our view of it.
A few years back now it was discovered that the company behind CloudPets — essentially an internet connected teddy bear — had left their database exposed publicly to the Internet without so much as a password to protect it.
In the database are references to almost 2.2 million voice recordings of parents and their children. With those references, you could retrieve the actual audio recordings of the conversations from the company’s open Amazon S3 buckets.
The person that originally discovered this problem tried to contact CloudPets three times to warn them, without any response. Then this database was then subject to a ransomware attack.
The CloudPets data was accessed many times by unknown parties before being deleted, by yet another unknown party.
Which is is sort of the problem here. Because suddenly, it’s not just your email or the photographs of your cat, but your location to the centimetre, your heart rate, your respiration rate. Not just how you slept last night, but with whom.
A few years ago iRobot the company that makes the Roomba, the adorable robotic vacuum cleaner, gave it the ability to build a map of your home while keeping track of its own location within it.
Then we found out that they were preparing to share those maps of people’s homes with their “commercial partners.” It turned out people aren’t quite as sure trading this sort data for services is such a good deal any more. Especially when the “free” services came bundled with smart things that we had to pay for with actual money.
Back in May last year a man named Masamba Sinclair rented a Ford Expedition from Enterprise Rent-a-Car. When he rented the car he connected it to his FordPass app. The app allows drivers to use their phones to remotely start and stop the engine, lock and unlock the doors, and continuously track the vehicle’s location.
Despite bringing it to the attention of both Enterprise, and Ford, we learned in October that five months after his returning rental car, and multiple renters later, he still had full remote control of the vehicle. After his story made worldwide news Enterprise did, eventually, manage to resolve the situation. But the underlying problem still exists. I believe Ford call it a feature, not a bug.
Then you have to think about failure modes for Internet of Things devices. You have to think about what the state of the device should be left in if the device itself fails, or if it simply loses its network connection, this is vastly more complicated for devices that rely on the cloud for the “smarts.”
The is the Petnet smart pet feeder, it is an automatic feeding device that manages portion size, food supply, and mealtimes for your pets all through an iPhone app. All the way back in 2016, so 4 years ago now, the Petnet pet feeder had a server outage, or rather the ‘third party servers’ they rely on had outage, and the devices stopped working. The servers were down for more than 12 hours, and during that time the smart feeders stopped feeding their furry charges.
Perhaps you’d think that four years on, this would be a solved problem for the Internet of Things? But just last week, the next generation of Petnet feeders again suffered from, more or less, the same problem. It’s actually hard to know if this was exactly the same problem, as information is still thin on the ground at this point, and Petnet isn’t answering email from journalists.
But this time, the system failure lasted a week. This is not a cheap device, it retails for over two hundred pounds. But really, ignoring that..?
“The cat dies!” should never be a failure mode.
These sorts of problems aren’t helped by the long life cycle that most Internet of Things devices are going to lead. The typical connected device could live on for 10 years, or more. Much more.
After all is the lifespan of a typical not-smart thermostat, and why would consumers expect a smarter one would need replacing sooner?
But a lot of the early connected devices are now abandonware. The rush to connect devices to the internet has led to an economic model that means manufacturers are abandoning devices before we as consumers are done with them.
To be fair, that model is forced on the companies selling the thing because the other Internet, the digital one, has made most consumers unwilling to subscribe to services and while we might be willing to pay for the device itself, a physical thing we can hold in our hands, we expect software and services to be “free.” But there is no cloud, there are only other people’s computers, and if we won’t pay for them, then someone else has to do that.
All of this causes yet another problem, ownership.
As customers we may have purchased a thing, but the software and services that make the thing smart remain in the hands of the manufacturer.
The data the thing generates belongs to, or at least is in possession of, the manufacturer, rather than the person that paid for the thing.
Last year for instance John Deere told farmers that they don’t really own their tractors but just licenses for the software that makes them go. That means that, not only can they not fix their own farm equipment, they can’t even take it to an independent repair shop for them to fix it. They have to use a John Deere dealership.
As a result there’s now a black market for cracked John Deere firmware on the dark web. Firmware that doesn’t lock down the tractor and gives farmers the option to service the thing themselves.
Privacy, security, dealing with failure, ownership, and abandonware.
All of these are problems that exist, or in the case of security and privacy, have been made far worse, in the Internet of Things by our insistence to make our smart devices not that smart, but instead cloud-connected clients for big data.
We need to sit back and think about why we’re doing what we’re doing. What the big data industry is for, rather than those tools that came along back in 2011.
We need to look around at the new tools that have become available.
Because in the end we never really wanted the data anyway, we wanted the insights and actions that the data could generate. Insights into our environment are more useful than write-only data collected and stored for a rainy day in a lake. Which made me think about something Alistair Croll said, all the way back at the start of this rollercoaster ride.
“Big data isn’t big, its the interaction of small data with big systems”—Alistair Croll, Solve for Interesting
It might be time to disassemble the big systems we spent 10 years building. Because I’m not sure we need them anymore. I’m not sure we need the cloud any more. At least, not everywhere.
Which is where the Coral Dev Board, from Google, and their Edge TPU comes in, it is a leading indicator. It’s part of a tidal wave of custom ASIC that we’ve seen released to market over the last year intended to speed up machine learning inferencing on the edge, no cloud needed.
No network needed. Take the data. Act on the data. Throw the data away.
By speed up, I really do mean that. On the left we have MobileNet SSD model running on the Edge TPU, on the right we have the same model running only on the CPU of the Dev Board, a quad-core ARM Cortex A53. The difference is dramatic, inferencing at around 75 frames per second, compared to 2 frames per second. No cloud needed. No networking needed.
Recently researchers at the University of Massachusetts, Amherst, performed a life cycle assessment for training several common large AI models.
They found that the process can emit the equivalent of more than 626 thousand pounds of CO2 — nearly five times the lifetime emissions of the average American car (including manufacture of the car itself).
Now I’ve been hearing about this study a lot, and I’ve got some problems with it, and how it looks at machine learning.
Firstly the sort of machine learning it looks at is natural language processing (NLP) models, that’s a small segment of what’s going on. But also it’s based on their own academic work, their last paper, where they found that the process of building and testing [the] final paper-worthy model required training 4,789 models over a six-month period. That’s just not been my experience about how, out in the real world, you train and build a model for a task.
The analysis that’s fine as far as it goes, but it ignores some things about how models are used, about those two stages. Because using a trained model doesn’t take anything like the resources required to train it in the first place, and just like software, once trained a model isn’t a physical thing. It’s not an object. One person using it, doesn’t stop someone else using it.
You have to split that sunk cost down amongst everyone or every object that uses it — potentially thousands or even millions of instances. It’s okay to invest a lot into something that’s going to be used a lot.
It also sort of ignores the facts about how long those models might hang around. The first job I ever had as an adult, fresh out of University was at a now defunct defence contractor. There I built neural network software for image compression. To be clear, this was during the first time this stuff was trendy, back in the early 1990’s when machine learning was still called neural networks.
The compression software I built around the neural network leaves rather specific artefacts, in the video stream, and every so often I still see those artefacts in video today in products by a certain large manufacturer who presumably picked up the IP of the defence contractor for a bargain price after it went bankrupt. Those networks, presumably now buried at the bottom of a software stack wrapped inside a black box with “here be magic” written on the outside — the documentation I left behind was probably that bad — are still around. Something like 25, to 30 years, later.
Which makes accessibility to pre-trained models, and what have become colloquially known as ‘model zoos’ rather important.
Because while you might drawn an analogy between a trained model and a binary, and the data set the model was trained on, and source code …it turns out that the data isn’t as useful to you as the model.
Because let us get real here, the secret behind the recent successes of machine learning isn’t the algorithms, this stuff has been lurking in the background for decades waiting for computing to catch up.
Instead, the success of machine learning has relied heavily on the corpus of training data that companies — like Google — have managed to build up. For the most part these training datasets are the secret sauce, and closely held by the companies, and people, that have them, but those datasets have also grown so large that most people, even if they had them, couldn’t store them, or train a new model based on them.
So unlike software, where we want source code not binaries, I’d actually argue that for machine learning the majority of us want models, not data. Most of us, developers, hardware folks, should be looking at inferencing, not training.
I’ll admit this is actually a fairly controversial opinion in the community, although not less so that many of my other opinions, just as strongly held.
It’s trained models makes it easy for you to go and build things like the retro rotary phone I built at the beginning of last year when I was talking mostly about building cloud connected machine learning applications.
Although around the same time I also showed a Raspberry Pi struggling really at the limits of its capabilities to do hot word voice recognition without talking to the cloud. However, things have moved on a lot in the last year.
Because over the last year there has been a realisation that not everything can, or should, be done in the cloud. The arrival of hardware designed to run machine learning models at vastly increased speeds, and inside a relatively low power envelopes, without needing a connection to the cloud, is starting to make edge based computing that much more of an attractive proposition for a lot of people. The ecosystem around edge computing is actually starting to feel far mature enough that real work can get done at long last.
On the market at the moment we have hardware for Google, Intel, and NVIDIA, with hardware from many smaller companies coming soon, or already now in production. Some of it designed to accelerate existing embedded hardware, like those USB sticks you can see attached to the Raspberry Pis here on the bench — from Intel and Google amongst others.
But some of it is designed as evaluation boards for System-on-Module or System-on-Chip units that are going to being made available in volume to industrial customers so they can build their own product around the silicon — like the Coral Dev Board from Google, or NVIDIA’s Jetson Nano.
Over the last six months I’ve been looking at machine learning on the edge, publishing a series of articles trying to answer some of the questions that people have been asking about inferencing on embedded hardware.
I based my benchmarking around the Raspberry Pi. Using both the Raspberry Pi 3, Model B+, and the Raspberry Pi 4, Model B.
The Raspberry Pi 3 is built around a 64-bit quad-core ARM Cortex-A53 clocked at 1.4GHz. You should bear in mind, the Cortex-A53 isn’t a performance core. It was designed as a mid-range core, and for efficiency.
However the Raspberry Pi 4 is built around an ARM Cortex-A72, and that means some big architectural changes. While the A53 used in the Pi 3 was designed as a mid-range core, the A72 is a performance core, so despite an apparently very small difference in clock speed, the real performance difference between the two boards is really rather significant.
I looked at TensorFlow, one of the most heavily used platforms to do deep learning, along with TensorFlow Lite, which is a version of TensorFlow for mobile and embedded device developers that uses quantisation to reduce computational overhead.
Quantising of neural networks uses techniques that allow for reduced precision representations of weights and, optionally, activations for both storage and computation. Essentially we’re using 8-bits to represent our tensors rather than 32-bit numbers. That makes things easier on low end hardware, but it also makes things a lot easier to optimise in hardware, for instance on custom silicon like Google’s Edge TPU.
However I also looked at a platform called AI2GO from a startup called Xnor.ai. They’d been in closed testing, but I’d been hearing rumours about them for a while, before I managed to get my hands on their framework.
Their platform uses a new generation of proprietary binary weight models, and as you’ll see the additional quantisation meant a significant performance gain. Enough in fact for Apple to buy them a few months ago for an estimated $200 million and yanked all their code and models offline.
It’s was actually sort of interesting. It is incredibly hard to find a good tutorial on how to do inferencing. A lot of the tutorials you’ll find on ‘how to get started with Tensor Flow’ talk about training models, some even just stop once you’ve trained the model. They don’t bother to use it.
I find this sort of puzzling, and presumably it speaks to the culture of the community around machine learning right now. Still sort of vaguely, academic. You see similar sorts of weirdness in with cryptography, a lot of discussion of mathematics, and little about using it.
So in any case feeding my test code for the various platforms an image containing two recognisable objects, a banana 🍌 and an apple🍎 we see different bounding boxes. The importance of bananas to Machine Learning researchers can not be over estimated.
The resulting bounding boxes are somewhat different between TensorFlow and AI2GO’s proprietary binary weight models. Not wrong. Not crazy, but definitely different.
With roughly twice the NEON capacity as the Raspberry Pi 3 we would expect to see roughly the same sort of speed up models running on the CPU on the Raspberry Pi 4, and as expected we do, for both TensorFlow and the AI2GO platform. The performance gains of those proprietary binary weight models over ‘traditional’ TensorFlow models are very clear.
Then on the right is the performance for Google’s Coral USB Accelerator using the Edge TPU, custom silicon as expected performs better. But the speed up we are seeing here is due, not to the faster processor, but the addition of a USB 3 bus on the Raspberry Pi 4.
You’re getting roughly 2 to 4 frames a second using TensorFlow directly on the Raspberry Pi 4 CPU, compared to around 12 or 13 frames per second using the proprietary binary weight models.
This shows the power of quantisation.
But it’s not until we look at TensorFlow Lite on the Raspberry Pi 4 that we see the real surprise. Here we see between a ×3 and ×4 increase in inferencing speed between our original TensorFlow benchmark, and the new results using TensorFlow Lite.
Running on the same hardware, and this isn’t a new fangled proprietary model, it’s the same MobileNet model, but we’re using a quantised version. You might expect some reduction in accuracy due to that, and while there was some observed, it wasn’t really statistically significant.
That sort of speed up is sort of astonishing, and really shows the power of quantisation. In fact, the decrease in inferencing times by using TensorFlow Lite and quantisation brings the Raspberry Pi 4 in into direct head-to-head competition with the custom silicon from both NVIDIA and Intel. A normal ARM chip doing deep learning inferencing just as fast, and for a lot less money, than custom silicon from the big players.
What all this comes down to is that the new Raspberry Pi 4 is probably the cheapest, most affordable, most accessible way to get started with embedded machine learning right now.
Use it on its own with TensorFlow Lite for competitive performance, or with the Coral USB Accelerator from Google for ‘best in class’ performance.
It’s notable that the only platform to keep up with TensorFlow Lite, Google’s own Edge TPU, also leans heavily on quantisation. My results are really starting make me wonder whether we’ve gone ahead and started optimising in hardware just a little too soon.
If we can get this much leverage out of software, out of quantisation, then perhaps we need to wait till the software in the embedded (edge) space has matured enough so that we know what to we should be optimising for?
In hindsight it makes Microsoft’s decision to stick with FPGA for now, rather than rolling their own custom silicon like everybody else seems to be doing, look a lot more sensible.
Now my benchmark figures were for image recognition, but that’s hardly the only thing that you can do locally, instead of in the cloud.
Right now while your voice assistants are listening to you, so are the humans behind them, so the arrival of speech-to-text engines like Picovoice’s Cheetah, which runs inside the power and resource envelope of a Raspberry Pi Zero is timely. No cloud needed.
That means that, unlike most current voice engines your conversation isn’t going leave your home, and won’t be monitored by humans for ‘quality control purposes’
But while inferencing speed is probably our most important measure, these are devices intended to do machine learning at at the edge.
That means we also need to pay attention to environmental factors.
Designing a smart object isn’t just about the software you put on it, you also have to pay attention to other factors, and here we’re especially concerned with heating and cooling, and the power envelope. Because it might be necessary to trade off inferencing speed against these other factors when designing for the Internet of Things.
The new TensorFlow Lite for Micro-controllers does exactly that. Because the custom accelerator hardware we’ve been seeing over the last year or so, that’s actually the high end of the embedded hardware stack.
The SparkFun Edge is the board that got spun up to act as the demo board for TensorFlow Lite for Micro-controllers. It’s built around the Ambiq Micro’s latest Apollo 3 micro-controller, that’s an ARM Cortex-M4F running at 48MHz with 96MHz burst mode operation, and has built in Bluetooth
It uses somewhere between 6 and 10 μA per MHz. So that’s around 0.3 to 0.5 mA running flat out and it draws just 1 μA in deep sleep mode with Bluetooth turned off
That’s insanely low powered.
For comparison the Raspberry Pi draws around 400 mA, and the ESP32 draws between 20 and 120 mA. Probably the closest comparison to Ambiq’s Apollo 3 is the Nordic nRF52840, and that still draws around 17 mA.
This chip at the heart of this board runs flat out within a power budget less than many micro-controllers draw in deep sleep mode, and it still manages to run TensorFlow Lite. While these tiny micro-controllers don’t have enough power to train neural networks, they can run inferences on existing models using tricks like model quantisation.
Real-time machine learning on a micro-controller board powered by a single coin cell battery that should last for months, even years. No cloud needed, no network needed, no private personal information leaves the board
At least on the open market right now, this is machine learning at the absolute limit of what our current hardware is capable of, it doesn’t get any cheaper and less powerful than this, and there is now even two competing forks of TensorFlow for Arduino, one from the TensorFlow Team at Google, and another from Adafruit in New York.
Making TensorFlow for Micro-controllers available from within the Arduino environment is a big deal, it is a huge change in the accessibility of machine learning in the emerging edge computing market. Arguably perhaps one of the major factors that drove the success of the Espressif ESP8266 was Arduino compatibility, and it’s going to really be fascinating to see if the same will happen with machine learning
But this isn’t the end of our journey down the stack.
TensorFlow Lite for Micro-controllers is a massively streamlined version of TensorFlow. Designed to be portable to “bare metal” systems, it doesn’t need either standard C libraries, or dynamic memory allocation. The core runtime fits in just 16KB on a Cortex-M3 and, with enough operators to run a speech keyword detection model, takes up a total of 22KB.
But when a lot of people talk about machine learning they use the phrase almost interchangeably with neural networks, but there is a lot more to it than just that.
You can use platforms like MicroML to go smaller.
Instead of neural networks, MicroML supports Support Vector Machines (SVMs). Good at classifying highly-dimensional features, they are easy to optimise for RAM-constrained environments. While TensorFlow Lite for Micro-controllers squeezes into its runtime into 16KB, MicroML lets you deploy models into just 2KB of memory. Machine learning on to an 8-bit micro-controller that costs pennies. No network needed.
The arrival of hardware designed to run machine learning models at vastly increased speeds, and inside a relatively low power envelopes, without needing a connection to the cloud, makes edge based computing that much more of an attractive proposition.
Which means that biggest growth area in machine learning practice over the next year or two could well be around inferencing, rather than training.
We’re right at the start of a shift in the way we collect data, and the amount of data collected.
We’re going to see a lot more data very soon, but most of it is going to live in low powered systems that don’t have to be connected to the Internet. The data, doesn’t have to go to the cloud.
Instead we can leverage new tools, like machine learning models, and the low powered hardware now appearing on the market that can run those models.
New tools that let us make local decisions.
Local decisions that mean the seemingly inevitable data breaches, and the privacy and ownership problems we’ve seen with the Internet of Things, aren’t necessarily going to be inevitable any more.
Of course. No new tool or technology is a panacea, capable of solving all our problems. I’m never going to be the one to argue that line of lunacy. Others might.
But if your solution to a problem exposes the underlying technology that solves it, you have failed. The whole point of technology is to get out of people’s way and let them do the things they need to do. Unless you work in technology, those things aren’t the technology itself.
The important thing is whether it solves the problem better than other methods, more seamlessly, and without the need for the end user to understand whatever technology you’ve used.
However I’ve got a sneaking suspicion that deploying a piece of hardware that does ‘magic’ without having to fiddle around with networking is going to be better in a lot of cases.
Of course deep learning models are incredibly easy to fool. Adding a simple physical perturbation — just four stickers! — to a stop sign, something that could easily be disguised as real graffiti, can fool a model.
This is what is called an adversarial attack, and those four stickers makes machine vision network designed to control an autonomous car read that Stop sign — still obviously a stop sign to us humans — as saying the ‘Speed Limit’ is 45 miles an hour. Not only would the car not stop, it might instead speed up.
You can launch similar attacks against face and voice recognition machine learning networks. For instance you can bypass the ‘liveness detection’ of Apple’s FaceID system, albeit under constrained and limited circumstances, using a pair of glasses with tape over the lens.
Of course, even moving data out of the cloud and onto our local devices doesn’t solve everything.
You wouldn’t take a hard drive and just throw it out in the trash, or put it up for sale on eBay, without at least wiping it properly. At least, you shouldn’t. However you may well still take your dead smart devices and throw them away. But, unsurprisingly perhaps, this turns out to be a bad idea as well.
This is the inside of a LiFM Mini smart bulb. If you’ve connected this bulb to your Wi-Fi network then your network password will be stored in plain text on the bulb, and can be easily recovered just by downloading the firmware and inspecting it using a hex editor.
In other words, throwing this lightbulb in the trash is effectively the same as taping a note to your front door with your wireless SSID and password written on it.
The press around Machine Learning, Artificial Intelligence, paints a picture which is really not in line with our current understanding of how AI systems are built today or in the foreseeable future.
Machine Learning systems are trained to a specific task, we are nowhere near general intelligence, and most researchers would argue that we don’t really understand how to get from here to there.
Privacy, security, morals, ethics around machine learning. All of this is now being debated, although for the most part it’s being done rather quietly. So as not to scare the public.
But what scares me the most is that as an industry we’ve proven ourselves perhaps uniquely ill-suited to self-regulate. Ten years of big data has convinced me that the technology industry is, arrogant and childish. ‘Move fast and break something’ shouldn’t apply to our personal privacy, or our civilisation!
Because of course this too shall pass. The Michigan Micro Mote, at least last time I looked, this is the smallest ‘real’ computer in the world. It features processing, data storage, and wireless communication. It is probably as close to the true smart dust vision from the early DARPA days as we’ve come so far.
They’re designed to harvest the energy from the environment around them and communicate via a mesh network. This is the next paradigm shift, perhaps?
In the future the phrase data exhaust will be not longer a figure of speech, it’ll be a literal statement. Your data will exist in a cloud, a halo of devices surrounding you, tasked to provide you with sensor and computing support as you walk along. Calculating constantly, consulting with each other, predicting, anticipating your needs. You’ll be surrounded by a web of distributed sensors, computing, and data.
Whether you like it or not.
Of course, it’s now been 30 years since the birth of the world wide web, which changed the Internet forever.
I still rather vividly remember standing in a draughty computing lab, with half a dozen other people, crowded around a Sun Sparc Station with a black and white monitor, looking over the shoulder of someone who had just downloaded first public build of NCSA Mosaic via some torturous method or another.
I remember shaking my head and saying “It’ll never catch on, why would you want images?” Which, perhaps, shows what I know, so maybe take all this with a pinch of salt.
Earlier this year, Zuckerberg stood up on stage at Facebook’s F8 conference and said “The Future is Private, ”and even if you don’t believe him, and let’s face it we haven’t been given any reason we should. The idea that this man, the man that ten years ago stood up and sold us on the mantra of the big data age, that privacy was no longer a social norm said this, tells us something.
It tells us that that age is over.
If we can give our users, our customers, our friends, the choice not to share their data with us and yet, still give ourselves the ability to obtain and act on insights. That’s not a bad thing, and we don’t need their data to do it any more. Or at least, we don’t need to keep it.
Moving what we can to the edge might not solve everything. But it’s going to be a good start. Take the data. Act on the data. Throw the data away.