Apple vs the FBI: Whoever wins, it’s a mess

Apple and the FBI. It’s the Rock ‘Em Sock ‘Em Robots fight that the movie Alien vs Predator should have been, but unlike Alien vs Predator, this one so far has failed to disappoint.

On one side, we have a giant tech megacorp that makes cellphones. Also other stuff, I hear, but these days mostly cellphones. On the other, we have the full force and might of the United States Government, in the form of the Federal Bureau of Investigation. In between, we have: Terrorists! Encryption! Civil liberties! Donald Trump spouting off!

The Internet is filled with conversations about the spat, much of which are either not technically correct or overtly technical. It’s my goal here to try to explain a very complex situation in a way that doesn’t require a high level of technical mastery. However, this is a technical issue, so there will be some geeky bits.


The Background

Last year, a couple of assholes named Syed Rizwan Farook and Tashfeen Malik decided they were going to express religion of peace by blowing away a bunch of people in San Bernardino, California. They decided, you see, that something something holy war something martyr God, and something something kill people whatever…I don’t know or particularly care about the details, and they’re not really relevant here. So far, so boring: some yahoos think there’s an invisible dude in the sky who wants them to kill some other people, it all ends in tears–a story that’s been playing out with minor unimportant variations since the dawn of civilization. The FBI investigated and decided they were “homegrown extremists” (no idea if they were organic or GMO-free) and not affiliated with any other terrorist groups or cells.

This is the part where things get interesting.

During the investigation, the FBI discovered that the yahoos had Android smartphones, which they destroyed prior to going on their rampage of murderous idiocy, and that one of them had an iPhone 5C provided by the company he worked for.

This is the logic board from an iPhone 5c. Like all iPhones, the user data on an iPhone 5c is encrypted. You need to unlock the phone in order to get at its contents. By default, the phone is locked with a 4-digit numeric code. If you don’t enter the code, the phone’s contents remain encrypted.

You can’t just read the information from the phone’s flash memory, because it’s encrypted. The FBI wants to read the contents of the phone, for reasons that aren’t clear to me (if there was anything sensitive on it, it’s hard to imagine he wouldn’t have smashed the phone before running off to kill people who had nothing to do with whatever grudge he imagined his invisible sky-man carried, like he did with his other phones), but whatever.

The FBI tried to read the phone’s contents, and discovered that the iPhone is actually rather secure. If you want to know the full details of how secure, there’s a PDF on Apple’s iPhone security here.

So they went to Apple.

This is where things get really interesting, and a lot of the conversation about the situation gets some important facts wrong.


The Problem

The iPhone’s files and such are encrypted. This is not simple home-grown encryption, either; it’s military-grade 256-bit AES encryption. It can not be defeated by any known attack. All the world’s computers combined would take about a billion years to brute-force the encryption, which is a bit more time than the FBI prefers to spend on this.

Now, there are some important things to understand here.

One is that nobody can break the encryption, not even Apple. Apple has no secret back doors or master passkeys to get at the contents of a locked phone, and that’s not (exactly) what the FBI is asking them to do.

The other is that the four-digit code you type into an iPhone is not the encryption key. The encryption key is made up of a secret, random number embedded into each phone at the moment of manufacture, combined with the passcode you set by means of some arcane mathematics that are beyond the scope of this blog post. Apple does not know the encryption key; they do not have a way to set the unique hardware number, and in any event it’s all tangled up with the passcode the user enters in order to create the encryption key anyway.

So here’s where things sit: The phone’s contents are encrypted. The FBI wants access to the phone for whatever reason. Apple can’t decrypt the phone. So what’s the deal?


The Tussle

The fact that the phone in question is an iPhone 5c is really, really important. If it had been a 5S or a 6, it wouldn’t matter, because Apple made a change in the inner workings of the later phones to prevent it from being asked to do precisely what it’s being asked to do.

So, here’s how it works.

iPhones run an operating system called iOS. iOS is digitally signed; that means Apple has a secret encryption key it embeds into iOS. The phone carries a special, immutable boot ROM that contains the decryption code for this key. If it starts to boot and sees an operating system not signed by Apple, or if the operating system is tampered with in any way, the phone refuses to boot. (This is different from and not related to jailbreaking an iPhone. Even a jailbroken phone will not boot a copy of iOS not signed by Apple.)

What does that mean? It means nobody on earth–literally–can make an operating system the phone will boot, except for Apple. If the FBI or anyone else tries to modify the iOS boot loader, the phone will not boot. Only Apple knows the key needed to change the iOS boot loader.

Now, a few other things you need to know about how an iPhone works.

If you type the wrong passcode into an iPhone, the phone lets you try again. If you get it wrong again, the phone lets you try again, but after that, things start getting harder. The phone starts introducing a delay before you can try again. That delay gets longer and longer the more you enter the wrong code. By the ninth time you enter the wrong code, the phone refuses to allow you to try again until an hour has passed.

There are 10,000 different possible combinations of four digits. If you can only try one per hour, it will take you more than a year to try them all. Good luck trying to brute force the passcode!

There’s another complication too. If you get it wrong 10 times, the phone wipes itself.

Here’s where the 5c thing gets important.

Starting with the iPhone 5S, Apple introduced the “Secure Enclave.” The Secure Enclave is a special chip (well, actually, it’s a special section of the processor chip) that has its own memory. It’s basically a tiny, highly secure, tamper-resistant computer.

The Secure Enclave keeps the phone’s decryption key in its own special memory and talks to the phone over a special-purposes, encrypted communication link. The rest of the phone does not know, or have access to, any information stored in the Secure Enclave.

When you enter the passcode, the phone sends the passcode to the Secure Enclave. The Secure Enclave says “yes” or “no” about whether the right code was entered. If the right code was entered, the Secure Enclave decrypts the phone. If it wasn’t, the Secure Enclave refuses to do so. It also starts a timer. While the timer is running, the Secure Enclave refuses to process any more passcode requests. That timer runs for longer and longer as you keep entering the wrong code. If you enter the wrong code 10 times, the Secure Enclave wipes the encryption key from its own memory and that’s it, you’re done. Trying to get at the phone’s contents after that means you’ll be banging away at it until the stars burn out.

But… This is not an iPhone 5S or later, it’s a 5c!

On the 5c, the time delay and wiping the phone are not handled by the Secure Enclave, they’re handled by the operating system. The operating system enforces the longer and longer delay and the operating system wipes the phone if you enter the wrong code 10 times.

The Secure Enclave is a bit of hardware that can’t be tampered with. But the operating system can be changed. So if you have an older iPhone, you could, in theory, put a different version of iOS on it. A special version, with the timer and the phone wipe disabled.

Except, oh no you can’t, because the phone will not run an operating system that isn’t signed by Apple.

So the FBI wants Apple to create a new version of iOS. A modified version that has no time delay if you get a wrong passcode and no phone wipe. And then they want Apple to sign it and put that new version of iOS onto the phone.

This will not give them the contents of the phone. What it will do is let them try passcode after passcode as fast as possible until they break in. Without a phone wipe, they can keep trying as many times as it takes. Without a delay, they can try all 10,000 combinations in days or weeks instead of years.

Of course, there’s an added wrinkle to all this. The FBI already has a copy of the phone’s data.

iPhones come with a subscription to Apple’s cloud service, iCloud. iPhone users can choose to have their data backed up to iCloud. The backup feature was turned on on this phone. The FBI asked for, and got, a copy of the phone’s data backed up on iCloud.

Unfortunately, the copy they got is out of date. They screwed up and asked the company that owns the phone to change the iCloud password in order to have a look at what was there. The company complied. The FBI looked at the iCloud backup. Then they turned on the iPhone. The iPhone couldn’t make a new backup to the cloud…because the password had been changed. The FBI thinks it’s possible there’s information on the phone that’s newer than the information in the cloud backup. They’re not sure, though, because…they can’t get into the phone.


The Rationalization

If an iPhone were a safety deposit box and Apple had the key, the government would normally just issue a subpoena for Apple to produce the key, assuming they didn’t just take a blowtorch to the box and be done with it.

But that’s not what the government has done here. They can’t subpoena Apple to produce the encryption key or the passcode because Apple does not have and can not get the encryption key or the passcode, and Apple has no magic backdoor.

So instead, they’ve turned to the All Writs Act of 1789, a law signed by this dude.

The All Writs Act is a law that allows the government to issue “all writs necessary or appropriate in aid of their respective jurisdictions and agreeable to the usages and principles of law.” Essentially, it lets Federal courts issue orders to private citizens in order to accomplish legal ends. A writ was originally a written order given by a monarch to a citizen compelling the citizen to do something. The way it’s used in the All Writs Act, it’s an order from a court compelling a citizen to do something.

Like, for example, write a new operating system. Because the court says so.

The All Writs Act was signed into law before the Bill of Rights existed. The Bill of Rights would seem to put some limits, at least, on what the government can order people to do. In this case, the FBI thinks that ordering a company to write a piece of software is within those limits.

It should be noted that this isn’t a matter of commenting out a few lines of code and hitting “compile.” There are, for good reason, legal guidelines that must be followed when writing investigatory forensic software. These legal guidelines are necessary to preserve the chain of evidence and show in court that the software didn’t modify the information on the device being investigated. The standards are fairly complex and are outlined on this page on the Digital Forensic Investigator Web site.

Basically, the gist of it is the software must be documented, must be subject to peer review, must be tested on target devices similar to the device being investigated to show that it works and won’t corrupt, delete, or modify information, and must pass independent judicial review of its reliability.

So basically, the FBI is asking Apple to go to considerable trouble to build a new operating system, test it, document it, submit it for examination, and load it onto an iPhone 5c, for the purpose of allowing the FBI to keep trying all 10,000 possible passcodes until they finally unlock it. They’re using a law written before the Bill of Rights existed that authorizes Federal courts to issue orders to private citizens to do this. Basically, the All Writs Act says “the government can order people to do any legal thing.” It has zero to say on the subject of what constitutes a “legal thing.”


The Real Battle

The FBI wants Apple to create a new version of its operating system, with certain key security features disabled, and load it onto the phone so that its passcode can be brute-force hacked and the contents read. They’re not asking Apple to decrypt the phone; Apple can’t do that. They’re not asking Apple to provide the passcode; Apple can’t do that either. They’re asking for a new operating system.

Would this new operating system allow them to get at any locked phone? No, it would not. iPhone 5s and later models have these security features in hardware, etched in silicon on the Secure Enclave. A new operating system can’t change that.

So what’s the big deal? Is Apple coddling terrorists, like the FBI director implies and Donald Trump spouts all over Twitter from his iPhone?

No. As with an argument between two lovers that ultimately ends in divorce, this fight is’t really about the stuff this fight is about. This fight isn’t about a work phone that used to belong to a terrorist asshole and probably contains fuckall of interest to the FBI. The terrorism angle is a convenient excuse, because the word “terrorism” is kind of magic spell that causes a whole lot of people (including, bizarrely, conservatives whose entire political philosophy is built on the foundation of distrusting the government) to take leave of their senses and do whatever they’re told.

But this fight isn’t about this phone.

Washington is afraid of encryption. Much as gun lovers and survivalists love to think Washington is afraid of their guns (which is laughable in its absurdity–the military has way more guns than you do, Tex), Washington is afraid of encryption.

This fight has been a very long time coming. The government has always hated and feared encryption, even as it has invested tremendous resources in making encryption better.

In the early 90s, the US passed laws banning export of encryption products. I still own a T-shirt that was legally classified as a “munition” back then, and that you could be arrested on Federal charges for wearing outside the US or showing to foreign nationals, because it’s printed with source code for encryption software. Finally, in 1996, Bill Clinton scrapped laws against exporting encryption software, largely because they were hurting US businesses overseas, and besides, the Russians already had strong crypto because–surprise!–they had mathematicians too.

The fear of the Russkies has faded into nothing–there’s an entire generation now old enough to read this blog post that grew up with the Cold War being something you read about in history books, not something you lived through. Now, the bogeyman du jour is terrorists, or maybe pedophiles, or hell, why not both?

Police don’t like locked phones and encrypted comms, and Congress has been wrestling with what to do about that for years.

The government has mulled banning strong encryption. Not just the US government, but every government. China wants to ban it. France just debated banning it. India is planning to ban it. The UK wants to ban it. Congress has considered banning it no fewer than three times in the last two years.

The arguments are always always the same: If people can talk without the government listening, the terrorists win. Or the pedophiles win. Or the pedophile terrorists win. Law enforcement can’t do its job without being able to see what’s on your smartphone, because reasons.

Apple argues that if the government succeeds in ordering it to write a new version of iOS to help them get onto this phone, they will feel free to order it to write other software for them as well. Write us software to let us turn on this suspect’s cell phone camera and microphone remotely! Write us software to make copies of this suspect’s email! No legal principle exists that would limit the authority of the government’s ability to order Apple to do things like this.

And that’s a nice, cuddly government filled with the milk of human kindness, like the US government believes the US government is. If Apple has the ability to do these things and can be compelled to do so, the Chinese will really like that. Apple argues that if the FBI succeeds, it will basically have to create a whole new software department–call it the Department of Undermining Our Security Department–to handle the flood of orders coming in to write custom software to disable this or that or the other security feature. And they might be right.

The government says nobody else will get this hacked iOS version (or versions, if other requests start rolling in). Apple says that’s naive. Hard to say what’s scarier, the FBI with rogue Apple-signed iOS software, the Chinese with rogue Apple-signed iOS software, or rogue Apple-signed iOS software leaking into the hands of organized crime.

There’s also the very real possibility that if the government has success here, sooner or later it will realize that a terrorist using an iPhone 6 will still be able to secure a phone in a way that neither Apple nor the government can do anything about, and start calling on Apple (and other companies) to weaken their encryption. The Secure Enclave with its hardware timer and self-vaporizing key is pretty damn secure. What happens if the government decides to tell Apple to tone things down a bit for the iPhone 7? That’s not impossible, and if Apple can be forced to write a new operating system to help law enforcement, changing the design of their chips to help law enforcement is a doddle.

Encryption is math. Math is math; math doesn’t care about bad guys or good guys or legal oversight. If there is a way to slip past an encryption method, that way works for everyone, good guys and bad guys alike, because math is math and math doesn’t care. If it works for the FBI, it works for Igor in the Russian mafia as well.

So that’s what’s going on, and that’s what’s at stake. It’s a problem that doesn’t readily boil down to sound bites or Tweets, and that means, I fear, that the public won’t really understand what’s happening until it’s been decided for them.

Sex tech: Wave your arms in the air like you just don’t care

The street finds its own uses for things.
—William Gibson, Burning Chrome

Imagine, if you will, a device you strap onto your lower arm. This device has a bunch of embedded myoelectric sensors that respond to hand movements, and accelerometers that track arm movements. Yoked to these is a Bluetooth transmitter that relays a stream of data about your hand position and arm motion to a computer or smartphone. Sound exciting?

Meet the Myo, a gadget in search of a purpose.

It’s a neat, if pricey, device still in search of a killer app. It comes with a PowerPoint plugin that lets you flip through slides by waving your arm in the air. There’s an interface for Skyrim, though it’s a bit laggy and you can’t play for long before your arm gets tired. There’s also a bit of software that lets you control a small drone with arm gestures, though with less precision than a conventional remote control. It’s very much a “build first, look for a function later” gadget, reminiscent of many tech innovations from the age of the dot-com bubble.

In most industries, the “build it and they will come” approach to project engineering is looked at with less and less favor these days. I am a long-time mad scientist with a particular flair for designing and building all manner of high-tech sex toys, though, so to me “build it and they will come” is what gets me out of bed in the morning.

As soon as I saw a demo of the Myo, my mind instantly went to sex. Controlling a device remotely by gesture and motion? What could possibly be more fitting in a sex toy? (In fairness, I did once, many years ago, build an Internet-controlled sex toy called the Symphony—a name that might perhaps be more appropriate for a device that you can operate by waving your arms. Dance, my puppets! Dance!)

So imagine my surprise when I Tweeted that this would make a cool controller for a sex toy and shortly thereafter one showed up on my doorstep, courtesy of AV Flox over at Slantist.

Electronically, the Myo is a Bluetooth LE radio, a set of myoelectric sensors, a suite of accelerometers, and a low-power processor core running proprietary firmware. Information from the myoelectric sensors is interpreted and translated into a set of posture information. This information is combined with data from the accelerometer and transmitted as a series of gestures and motions.

Conceptually, it looks a bit like this:

The Myo communicates with a laptop or smartphone. The laptop or smartphone interprets the messages from the Myo, then sends appropriate commands to an Arduino with a Bluetooth board connected, instructing it to to run (or stop) a vibrator attached to the motor driver.

The Arduino is a small single-board computer that was designed to do easy experimenting with programmable devices. Think of something like a Raspberry Pi, only far simpler and without an operating system. You can get many additional boards for the Arduino to do all sorts of things—Bluetooth, WiFi, networking, sensors, motor drivers, and other boards exist. The Arduino and its add-on boards are designed to be stacked on top of one another, to make project development easy.

The laptop or smartphone is necessary because of Bluetooth’s design. Bluetooth is a computer-to-peripheral technology. A Bluetooth network uses a master/slave topology, which means a Bluetooth peripheral can’t communicate directly with another Bluetooth peripheral—a “master” device like a laptop or smartphone is needed as an intermediary. When I first started working on a Myo-controlled sex toy, I did the development on a Macbook Pro laptop.

The Hardware

For the first-generation version of the gesture-controlled sex toy, I opted to use an Arduino Uno with a Red Bear Bluetooth shield and one of Kyle Machulis’ Pen15 vibrator controller boards, largely by virtue of the fact that I already happened to have all of them sitting on my workbench.

The Arduino is a small electronics board, roughly the size of an index card, that’s easy to program and capable of talking to all sorts of peripheral hardware. As a controller for a sex toy, it’s a bit large and clunky. Combined with a Bluetooth board and a motor control board, the whole ensemble is about as big as a pack of cigarettes; not exactly discreet. There are several much smaller development boards available, and a later version of this project will probably be about the size of a quarter.

The Arduino, Bluetooth board, and motor controller, all stacked atop one another, look like this:

The blue board on the bottom is the Arduino itself, and contains the processor, power supply, and USB interface for programming. The red board in the middle is the Bluetooth board. The green board on top is the Pen15, an interface board designed specifically to run a sex toy from an Arduino. All together, this stack of boards cost about $40 or so.

The Software

Assembling the stack of components to make a Myo-controlled sex toy was the easy part. Writing the software turned out to be a bit more aggravating.

There are two parts to the software: a program running on the laptop (or smartphone, but for convenience I wrote the first version on my laptop), and a program running on the Arduino. The laptop software needed to pair with the Myo and the Arduino’s Bluetooth card, accept incoming data from the Myo, figure out how to translate those data into sex toy functions, and then send appropriate commands to the Arduino. The software on the Arduino needed to accept those commands and run the vibrator accordingly.

The Myo does a lot of on-board processing to figure out what hand gestures are being done, then sends the gesture data to the computer. It can recognize certain gestures, like making a fist, spreading your fingers apart, and tapping your thumb and forefinger together. It also sends information from the accelerometers, to report motion data.

For the first version, I wanted to keep things simple. I decided to look only at hand gestures, rather than arm motion. Making a fist, I decided, would turn the vibrator off; spreading my fingers would turn it on. (I opted not to control the speed of the vibrator, even though this is fairly straightforward for the Arduino to do, just to keep things simple.) This let me ignore accelerometer data and look only at hand gestures.

The Arduino software was relatively straightforward. The Arduino Bluetooth card comes with a programming library, which, much to my dismay, failed to work right out of the box. That’s surprisingly common in the world of Arduino development, where hardware and software is often designed by small groups of dedicated enthusiasts and may or may not work as expected the first time. An hour’s worth of Googling and some trial and error let me get the Arduino Bluetooth library working, and after that, things were a lot easier. I chose a command that would mean “vibrator on” and another that would mean “vibrator off,” and wrote a simple program that would poll the Bluetooth card looking for those commands and send the appropriate signal to the Pen15 board. All in all, the Arduino side of the equation took an evening to get sorted.

The computer/Myo side was a bit more complicated. The Myo I received was one of the first to ship, and the Myo’s software development kit was a mess when it was first released. (It’s still something of a mess now.) I had considerable difficulty pairing with both the Myo and the Arduino—something that wasn’t helped by the fact that Mac development is usually done in a language called Objective-C, and my experience with Objective-C is limited. It’s mostly like C++, mostly, but there are just enough differences to trip up anyone accustomed to C++.

I finally gave up on accessing the Myo directly and opted for a shortcut. The Myo comes with software that maps Myo gestures onto the keyboard, so I decided to make things even easier by going that route. I mapped an open-hand gesture to the letter ‘a’ on the keyboard and a fist to the letter ‘z,’ and decided to write the software so that it would send a “vibrator on” signal when it saw the letter ‘a’ and send a “vibrator off” signal when it saw the letter ‘z.’ I figured once I had that working, I could get more fancy and sort out accessing the Myo directly later.

It took a good bit of time to get even that part working. The software development kit for the Arduino Bluetooth card is, if anything, in an even more sorry state than the Myo SDK. It took a lot of hair-pulling to get the sample code to work properly, and it tended to break whenever I tried to modify it.

In the end, I did finally get it to work, after a fashion. It was (and still is) quite crude: it recognizes only two Myo gestures, which it translates into “run the vibrator at full speed” and “turn the vibrator off.” The software still has a maddening habit of losing touch with the Arduino occasionally, for no reason I can discern, but it works.

The test

I decided to try out the vibrator with one of my girlfriends who was visiting from the UK, where she lives. We had just finished a whirlwind three-week camping tour of ghost towns through the Pacific Northwest, a journey I am still chronicling.

We spent her last night in Portland at a hotel near the airport, and I thought, hey, this would be an awesome time to take the new toy for a spin, and maybe even get some video of the device in action. She thought that idea sounded splendid.

Unfortunately, the software had other ideas. As often happens, somewhere between being tested on my workbench and being tried in the real world, it decided to quit working. I debugged frantically while she lay naked in bed waiting. Eventually, she fell asleep, and the opportunity was lost.

Later testing would have to wait for a more favorable time. Eventually I was able to get it working again, but the moment to use it with her had passed.

The future

The current prototype gesture-controlled sex toy is quite primitive. Put together, it looks like this:

The hardware is still clunky. I plan to rebuild it using a DF Robot Bluno, which combines the Arduino and Bluetooth on a tiny board roughly the size of a quarter.

This should make it possible to create a discreet, miniaturized sex toy that can be worn in public. I have one of these sitting on my workbench, but haven’t had a chance to play with it.

Eventually, when I’ve made more progress on the strapon the wearer can feel and I have time to return to this project, I plan to refine the software, adding accelerometer control and allowing the vibrator to be controlled more precisely—perhaps by adding patterns to the vibration. (I have visions of doing a PowerPoint presentation at a business function while one of my partners sits in the audience wearing this device, as it responds to the same gestures I’m using to control the PowerPoint slides.)

Finally, I want to compile the control software for my iPhone, so I don’t have to lug around a laptop wherever I might want to use it. I can keep the iPhone in my pocket, where it silently listens to the Myo and sends signals to the sex toy.

The possibilities of remotely operated, Bluetooth-controlled sex toys that respond to wireless sensors, controllers, and other devices has a great deal of potential, especially if you’re a mad engineer like me. There’s rich territory here, just begging to be explored by intrepid adventurers. The early Myo prototypes are, I think, merely the tip of the proverbial iceberg. I can hardly wait to see what else is possible!

ISIS, WordPress, and insecure Web hosts, oh my!

It is a fact universally acknowledged that running a WordPress site is a dangerous thing to do. WordPress is often attacked by hackers, because so many sites run it and so many people are not good about installing security updates. The hackers will use the commandeered sites for all sorts of nefarious purposes: installing malware, hosting phony bank pages that they then spamvertise in “Update Your Account Now” spam emails, hosting redirectors that lead people to spam or porn or phish pages.

I get a lot of spam emails, and when they lead to phony bank pages I will often check the top level of the site that the phony bank page is hosted on to see what’s going on. As often as not, the phony bank page is living on a WordPress site whose owner chose a bad password or was negligent about updating, and got pwn3d.

So it was that I found a fake PayPal page and, when I checked the home page of the hijacked site it lived on, I saw something odd: the home page had been deleted and replaced with a message reading “HACKED BY DARKSHADOW-TN AND ANONCODERS”.

I didn’t realize I was about to stumble on a massive (and still ongoing) security breach at two large Web hosting companies, Arvixe and Eleven2.

   

Curious, I did a Google search for that phrase (hacked by darkshadow-tn and anoncoders) and found thousands of Web sites that had been hacked and defaced with that message. And I do mean thousands–nearly three thousand in all.

I started working through the Google list, visiting each Web site to see if the defacement was still present. I discovered that there were three basic types of defacement, almost all of them done to WordPress sites.

Some sites had their content removed and replaced with a simple text message.

Some had the content left alone, but the page title changed to read “+ADw-/title+AD4-HACKED BY DARKSHADOW-TN AND ANONCODERS+ADw-DIV style+AD0AIg-DISPLAY: none+ACIAPgA8-xmp+AD4-“. This appears to be a misconfiguration of the automated tools the hackers used to deface the sites; it seems the hackers were trying to insert this in the page’s body.

Some had a defacement message injected into the body of the Web site, usually at the top.

So, who are Darkshadow and Anoncoders?

Anoncoders is a loosely-organized group of Islamic computer hackers who use automated tools to hack poorly secured Web sites and deface them with anti-Israeli and pro-Muslim messages. They even have a Facebook page and everything.

Darkshadow is a group of pro-ISIS Muslim extremists who, like Anoncoders, often hack sites to deface them with pro-ISIS, anti-Israel, and/or anti-Western messages. They used to have a Facebook page, but it’s gone as of the time of writing this.

So we’ve got a couple of pro-Muslim, anti-Western hacker groups who generally use automated tools to hack low-lying fruit, such as WordPress and Drupal sites that are running old versions or otherwise poorly secured. So far, so ordinary–dare I say, even boring. These kinds of attacks are a dime a dozen.

I started making a list of hacked sites, checking who the Web host was, then sending emails to the Web host abuse address letting them know they were hosting hacked sites.

That was when things got interesting.

As I went through the results of the Google search, cataloging thousands of hacked sites, I started noticing something weird: all the hacked sites were on only two hosting companies. Roughly half of them were hosted by Arvixe, and the other half were hosted by Eleven2, an outfit that’s a subsidiary of a company called IH Networks.

That raised the possibility that this wasn’t merely an automated, script-kiddie attack against a bunch of low-hanging fruit, but a breach of two hosting company’s Web control panel software or some other weak link in the hosting companies’ software infrastructure.

I sent off emails to both Web hosts letting them know they had been the subject of a massive breach.

Unsurprisingly, neither of them responded. I say “unsurprisingly” because I have a long history of discovering massive security breaches at large, popular Web hosting companies that go unrepaired for months or even years.

I sent notifications to both of those Web hosting companies about three weeks ago. Upon re-examining the hacked sites today, I discovered, disappointingly, that the security problems have not been fixed and the sites remain compromised.

So I went back and looked at past abuse reports I have filed with those companies. This is my first contact with Eleven2, but I noticed that hacked sites I had alerted Arvixe to as long ago as last September are still compromised.

It seems there is a lesson here: Both Arvixe and Eleven2 have severe ongoing security problems and are more or less completely indifferent to fixing the problem.

If you use either of these Web hosting companies, I would suggest it might be prudent to examine your site carefully for security breaches, and to move to a different Web host as promptly as possible. It’s never a good sign when a Web host ignores reports that their servers have been breached by ISIS-affiliated hackers.

Call to the Lazyweb: Backup

I have a problem I’ve been beating my head against for a while now, and I’ve finally given up and decided to put this out there to the hive-mind of the Internet.

I have a laptop I want to keep regularly backed up. I have external hard drives that I use to do this, one that I carry with me and one that stays in my office in Portland. I use cloning software to duplicate the contents of the laptop onto them.

But I also want to do incremental backups, Dropbox-style, to a server I own.

I do have a paid Dropbox account and I do use it. (I also have a paid Microsoft OneDrive account.) But I’d really prefer to keep my files on my own server. What I want is very simple: the file and directory structure on the laptop to be mirrored automatically on my server, like such:

This should not be difficult. There is software that should be able to do this.

What I have tried:

Owncloud. They no longer support Mac OS X. Apparently they ran into problems supporting Unicode filenames and never solved it, so their solution was to drop OS X support.

BitTorrent Sync. This program is laughably bad. It works fine, if you’re only syncing a handful of files. I want to protect about 216,000 files, totaling a bit over 23 GB in size. BT Sync is strictly amateur-hour; it chokes at about 100,000 files and sits there indexing forever. I’ve looked at the BT Sync forums; they’re filled with people who have the same complaint. It’s not ready for prime time.

Crashplan. Crashplan encrypts all files and stores them in a proprietary format; it does not replicate the file and folder structure of the client on the server. I’m using it now but I don’t like that.

rsync. It’s slow and has a lot of problems with hundreds of thousands of files. The server is also on a dynamic IP address, and rsync has no way to resolve the address of the server when it changes.

Time Machine Server. Like CrashPlan, it keeps data in a proprietary format; it doesn’t simply replicate the existing file/folder structure, which is all I want. Like rsync, it has no way to cope with changes to the server’s IP address.

So you tell me, O Internets. What am I missing? What exists out there that will do what I want?

WordPress security issues: this is a bad one, folks

It’s been a bad week for WordPress. If you’re a WordPress user, I highly recommend you check as soon as possible to ensure your site is updated, all your plugins are up to date, and your site is free of unexpected users and malicious combat.

WordPress 4.4.2 was released February 2. This release fixes two known security flaws.

Hot on the heels of this security release come two worrying developments. The first, reported on over at the Wordfence blog, concerns a new WordPress attack platform that makes it easier than ever for criminals to attack WordPress sites. From the article:

The attack platform once fully installed provides an attacker with 43 attack tools they can then download, also from pastebin, with a single click. The functionality these tools provide includes:

  • Complete attack shells that let attackers manage the filesystem, access the database through a well designed SQL client, view system information, mass infect the system, DoS other systems, find and infect all CMS’s, view and manage user accounts both on CMS’s and the local operating system and much more.
  • An FTP brute force attack tool
  • A Facebook brute force attacker
  • A WordPress brute force attack script
  • Tools to scan for config files or sensitive information
  • Tools to download the entire site or parts thereof
  • The ability to scan for other attackers shells
  • Tools targeting specific CMS’s that let you change their configuration to host your own malicious code

The post includes a video of the attack platform in action.

Second, from Ars Technica, is a report of WordPress sites being hacked and made to download ransomware to visitors’ computers.

It’s not currently clear how the sites are being compromised, but it may be via an unknown zero-day security exploit. From the article:

According to a Monday blog post published by website security firm Sucuri, the compromised WordPress sites he observed have been hacked to include encrypted code at the end of all legitimate JavaScript files. The encrypted content is different from site to site…

It’s not yet clear how the WordPress sites are getting infected in the first place. It’s possible that administrators are failing to lock down the login credentials that allow the site content to be changed. It’s also feasible that attackers are exploiting an unknown vulnerability in the CMS, one of the plugins it uses, or the operating system they run on. Once a system is infected, however, the website malware installs a variety of backdoors on the webserver, a feature that’s causing many hacked sites to be repeatedly reinfected.

What can you do to protect your WordPress site? If you’re running WordPress, I strongly, strongly urge you to do the following:

  • Use strong admin passwords! I can not emphasize this enough. Use strong admin passwords! Criminals use automated tools to scan thousands of WordPress sites an hour looking for weak passwords. A normal WordPress install will be scanned dozens to hundreds of times a day. Use strong admin passwords!
  • Update all your sites RELIGIOUSLY. When a WordPres security patch is released, criminals will go to work examining the patch to see what it fixes, then develop automated tools to automatically hack unpatched sites. You may have only 24-48 hours between when a security patch comes out and when people start using tools that will automatically compromise sites that haven’t installed the patch. Turn on automatic updates. Keep on top of your site.
  • Install a tool like WordFence. This free plugin will protect your site by locking out people who use known attack tools or brute-force password guessing attempts. It will notify you by email of hack attempts and updates that need to be installed.
  • Install a tool like WPS Hide Login to move your login page to a hidden location, like /mysecretlogin instead of /wp-login.php. This will go miles toward securing your site.

I highly recommend you install the free Infinite WP tool as well. It’s a plugin plus a Web app that will notify you of updates and allow you to update one or many WordPress sites with just one button click. This is a great way to keep on top of security patches.

Also, absolutely do not assume you’re safe because you’re an obscure little blog that nobody cares about. The criminals will still find you. They use totally automated tools to scan for vulnerable WordPress sites looking for installations to exploit. It doesn’t matter if only you and your mom know about your site–criminals will find it and will exploit it.

Stay safe!

Update #5 on the sex toy you can feel

A lot of folks have been emailing me asking for an update to the project I am working on to build a strapon dildo covered with sensors that the wearer can actually feel.

I’ve been spending so much time working on this project that it’s been hard to keep up with blogging about it. I’m currently halfway done with a stage 2 prototype that’s way more advanced than the first prototype, and I’m excited about getting it done. We’ve also been talking to several amazing mentors and investors who are helping to make this thing a reality.

I also had overwhelming responses to our surveys–apologies to everyone who wanted to do a Skype or in-person interview I wasn’t able to schedule. The schedule filled up within minutes of putting out the call for interviews. I did a survey that got more than 1,700 responses and dozens of in-person and Skype interviews, which told us that there are lots of people who want this device.

I am really excited. I’ve had really positive conversations with a couple of investors in the last couple of weeks and hope to have all kinds of good news for everyone soon.

Want to keep up with developments? Here’s a handy list of blog posts about it:
First post
Update 1
Update 2
Update 3
Update 4

#WLAMF no. 36: Antique Calculators

I first went off to college in 1984. (I say “first” because I’ve had a somewhat checkered college career, with many false starts.) On the occasion of my going off to school, to learn (or so I thought) computer engineering, I got myself a programmable calculator: a Radio Shack EC-4004.

I’ve moved rather a lot since then, but somehow, and without any deliberate intention on my part, that calculator seems to have stuck with me…kind of like a cursed ring in an old Dungeons & Dragons game, with less eternal suffering and more calculating definite integrals. (Yes, it could do that.)

I found the calculator a few days back, while I was digging through a drawer looking for a roll of tape. It’s been through a lot; it’s covered with dust, and I have a hazy memory of spilling a shot of apple schnapps on it at some point in the past.

I flicked the power switch, not expecting a lot, and…it worked! The batteries, which have never been replaced and are now old enough to vote and drink alcohol, still worked a treat.

As powerful as modern smartphones and similar devices are, there’s no chance they’ll still work after a similar amount of time. Flash memory is cheap but transient, and loses information over time. Modern lithium ion batteries degrade over time. Leave an iPhone in a drawer for twenty years and it will be a paperweight on the other side.

This old calculator has a paltry amount of processing power compared even to a modern watch, but you gotta admire the way it just keeps going.


I’m writing one blog post for every contribution to our crowdfunding we receive between now and the end of the campaign. Help support indie publishing! We’re publishing five new books on polyamory in 2015.

#WLAMF no. 9: Fusion

A lot of the world’s social, economic, and resource problems are, when you come down to it, power problems. I don’t mean political power; I mean energy. Electricity.

Take fresh water, for instance. Three-quarters of the planet’s surface is covered by the stuff, yet much of the world doesn’t have reliable access to safe, clean water. 780 million people don’t have regular access to clean water. Nearly four million people die a year from water-bourne illness.

If we had unlimited quantities of cheap, clean energy, water would stop being a problem overnight. It’s easy to desalinate seawater…easy, but not cheap. The process requires enormous inputs of energy, and energy is expensive.

The holy grail of energy is, and has always been, fusion power. Fusion power offers vast quantities of energy from seawater…if we can make it work. And we’ve been chasing it for a while, though never with any serious determination; the world’s annual budget for fusion research is about 1/18th the annual revenue of the National Football League. (In the US, the annual budget for fusion research is less than what the Government Accountability Office spends on paperwork.) Fusion power promises one-stop shopping for reversing global carbon emissions, improving access to fresh water all over the world, raising the standard of living for developing nations, moving toward non-polluting transportation…

…if we can make it work.

It’s been a long road. A lot of engineers thought we’d have the problem licked by the mid-1960s. Here we are in 2014, and it’s only been in the last two years that teams at MIT and Lawrence Livermore have actually made fusion reactors that produce net positive energy…for short periods of time. It’s a very, very difficult nut to crack.

Enter Lockheed Martin.

Lockheed Martin recently announced that their Skunkworks team has been quietly, and secretly, working on fusion power for a while. And they claim to be within 5 years of an operating prototype of a compact fusion reactor.

Now, I am of two minds about this.

Pros:

– It’s the fucking Lockheed Martin fucking Skunkworks. These are not a bunch of cranks, kooks, or pie-in-the-sky dreamers. These guys built the SR-71 in the early 1960s, and the F-117 Stealth fighter back when the Radio Shack TRS-80 was the state of the art for personal computers.
– Lockheed doesn’t seem the kind of company to stake their reputation on a claim unless they’re really, really sure.
– They’re exploring deuterium-tritium fusion, which is a lot easier than ordinary hydrogen-hydrogen fusion of the sort that happens in the sun.
– Did I mention it’s the fucking Lockheed Martin fucking Skunkworks? They have money, engineering expertise, and problem-solving experience by the metric ton. They are accustomed to solving hard engineering problems 20 years before anyone else in the world even knows they can be solved.

Cons:

– Fusion is hard. The pursuit of fusion has left a lot of broken dreams in its wake.
– The design they propose encloses a set of superconducting magnets inside the fusion chamber. That’s clever, and solves a lot of problems with magnetic containment, but superconducting magnets are fragile things and the inside of a fusion chamber is as close as we can get to hell on earth.
– Fusion creates fast neutrons. Those fast neutrons tend to run into stuff and knock it all out of whack. Solving the problem of the reactor vessel degrading under intense neutron flux is non-trivial; in fact, that’s one of the key objectives of the multibillion-dollar International Thermonuclear Experimental Reactor being built by a consortium of countries in France.

Fusion power, if we can make it work, would likely (and without hyperbole) be one of the most significant achievements of the human race. It could and very likely would have farther-reaching impacts than the development of agriculture or the invention of iron, and would improve the standard of living for billions of people to a greater extent than any other single invention.

For that reason alone, I think it’s worth pursuing. I’d like to see it better funded…say, maybe even on the same scale as the NFL. I’m not sure of Lockheed can deliver what they’re promising, but I am very, very happy they’re in the race.


I’m writing one blog post for every contribution to our crowdfunding we receive between now and the end of the campaign. Help support indie publishing! We’re publishing five new books on polyamory in 2015: https://www.indiegogo.com/projects/thorntree-press-three-new-polyamory-books-in-2015/x/1603977

Some thoughts on machine learning: context-based approaches

A nontrivial problem with machine learning is organization of new information and recollection of appropriate information in a given circumstance. Simple storing of information (cats are furry, balls bounce, water is wet) is relatively straightforward, and one common approach to doing this is simply to define the individual pieces of knowledge as objects which contain things (water, cats, balls) and descriptors (water is wet, water flows, water is necessary for life; cats are furry, cats meow, cats are egocentric little psychopaths).

This presents a problem with information storage and retrieval. Some information systems that have a specific function, such as expert systems that diagnose illness or identify animals, solve this problem by representing the information hierarchically as a tree, with the individual units of information at the tree’s branches and a series of questions representing paths through the tree. For instance, if an expert system identifies an animal, it might start with the question “is this animal a mammal?” A “yes” starts down one side of the tree, and a “no” starts down the other. At each node in the tree, another question identifies which branch to take—”Is the animal four-legged?” “Does the animal eat meat?” “Does the animal have hooves?” Each path through the tree is a series of questions that leads ultimately to a single leaf.

This is one of the earliest approaches to expert systems, and it’s quite successful for representing hierarchical knowledge and for performing certain tasks like identifying animals. Some of these expert systems are superior to humans at the same tasks. But the domain of cognitive tasks that can be represented by this variety of expert system is limited. Organic brains do not really seem to organize knowledge this way.

Instead, we can think of the organization of information in an organic brain as a series of individual facts that are context dependent. In this view, a “context” represents a particular domain of knowledge—how to build a model, say, or change a diaper. There may be thousands, tens of thousands, or millions of contexts a person can move within, and a particular piece of information might belong to many contexts.

What is a context?

A context might be thought of as a set of pieces of information organized into a domain in which those pieces of information are relevant to each other. Contexts may be procedural (the set of pieces of information organized into necessary steps for baking a loaf of bread), taxonomic (a set of related pieces of information arranged into a hierarchy, such as knowledge of the various birds of North America), hierarchical (the set of information necessary for diagnosing an illness), or simply related to one another experientially (the set of information we associate with “visiting grandmother at the beach).

Contexts overlap and have fuzzy boundaries. In organic brains, even hierarchical or procedural contexts will have extensive overlap with experiential contexts—the context of “how to bake bread” will overlap with the smell of baking bread, our memories of the time we learned to bake bread, and so on. It’s probably very, very rare in an organic brain that any particular piece of information belongs to only one context.

In a machine, we might represent this by creating a structure of contexts CX (1,2,3,4,5,…n) where each piece of information is tagged with the contexts it belongs to. For instance, “water” might appear in many contexts: a context called “boating,” a context called “drinking,” a context called “wet,” a context called “transparent,” a context called “things that can kill me,” a context called “going to the beach,” and a context called “diving.” In each of these contexts, “water” may be assigned different attributes, whose relevance is assigned different weights based on the context. “Water might cause me to drown” has a low relevance in the context of “drinking” or “making bread,” and a high relevance in the context of “swimming.”

In a contextually based information storage system, new knowledge is gained by taking new information and assigning it correctly to relevant contexts, or creating new contexts. Contexts themselves may be arranged as expert systems or not, depending on the nature of the context. A human doctor diagnosing illness might have, for instance, a diagnostic context that behaves similarly in some ways to the way a diagnostic expert system; a doctor might ask a patient questions about his symptoms, and arrive at her conclusion by following the answers to a single possible diagnosis. This process might be informed by past contexts, though; if she has just seen a dozen patients with norovirus, her knowledge of those past diagnoses, her understanding of how contagious norovirus is, and her observation of the similarity of this new patient’s symptoms to those previous patients’ symptoms might allow her to bypass a large part of the decision tree. Indeed, it is possible that a great deal of what we call “intuition” is actually the ability to make observations and use heuristics that allow us to bypass parts of an expert system tree and arrive at a leaf very quickly.

But not all types of cognitive tasks can be represented as traditional expert systems. Tasks that require things like creativity, for example, might not be well represented by highly static decision trees.

When we navigate the world around us, we’re called on to perform large numbers of cognitive tasks seamlessly and to be able to switch between them effortlessly. A large part of this process might be thought of as context switching. A context represents a domain of knowledge and information—how to drive a car or prepare a meal—and organic brains show a remarkable flexibility in changing contexts. Even in the course of a conversation over a dinner table, we might change contexts dozens of times.

A flexible machine learning system needs to be able to switch contexts easily as well, and deal with context changes resiliently. Consider a dinner conversation that moves from art history to the destruction of Pompeii to a vacation that involved climbing mountains in Hawaii to a grandparent who lived on the beach. Each of these represents a different context, but the changes between contexts aren’t arbitrary. If we follow the normal course of conversations, there are usually trains of thought that lead from one subject to the next; and these trains of thought might be represented as information stored in multiple contexts. Art history and Pompeii are two contexts that share specific pieces of information (famous paintings) in common. Pompeii and Hawaii are contexts that share volcanoes in common. Understanding the organization of individual pieces of information into different contexts is vital to understanding the shifts in an ordinary human conversation; where we lack information—for example, if we don’t know that Pompeii was destroyed by a volcano—the conversation appears arbitrary and unconnected.

There is a danger in a system being too prone to context shifts; it meanders endlessly, unable to stay on a particular cognitive task. A system that changes contexts only with difficulty, on the other hand, appears rigid, even stubborn. We might represent focus, then, in terms of how strongly (or not) we cling to whatever context we’re in. Dustin Hoffman’s character in Rain Man possesses a cognitive system that clung very tightly to the context he was in!

Other properties of organic brains and human knowledge might also be represented in terms of information organized into contexts. Creativity is the ability to find connections between pieces of information that normally exist in different contexts, and to find commonalities of contextual overlap between them. Perception is the ability to assign new information to relevant contexts easily.

Representing contexts in a machine learning system is a nontrivial challenge. It is difficult, to begin with, to determine how many contexts might exist. As a machine entity gains new information and learns to perform new cognitive tasks, the number of contexts in which it can operate might increase indefinitely, and the system must be able to assign old information to new contexts as it encounters them. If we think of each new task we might want the machine learning system to be able to perform as a context, we need to devise mechanisms by which old information can be assigned to these new contexts.

Organic brains, of course, don’t represent information the way computers do. Organic brains represent information as neural traces—specific activation pathways among collections of neurons.

These pathways become biased toward activation when we are in situations similar to those where they were first formed, or similar to situations in which they have been previously activated. For example, when we talk about Pompeii, if we’re aware that it was destroyed by a volcano, other pathways pertaining to our experiences with or understanding of volcanoes become biased toward activation—and so, for example, our vacation climbing the volcanoes in Hawaii come to mind. When others share these same pieces of information, their pathways similarly become biased toward activation, and so they can follow the transition from talking about Pompeii to talking about Hawaii.

This method of encoding and recalling information makes organic brains very good at tasks like pattern recognition and associating new information with old information. In the process of recalling memories or performing tasks, we also rewrite those memories, so the process of assigning old information to new contexts is transparent and seamless. (A downside of this approach is information reliability; the more often we access a particular memory, the more often we rewrite it, so paradoxically, the memories we recall most often tend to be the least reliable.)

Machine learning systems need a system for tagging individual units of information with contexts. This becomes complex from an implementation perspective when we recall that simply storing a bit of information with descriptors (such as water is wet, water is necessary for life, and so on) is not sufficient; each of those descriptors has a value that changes depending on context. Representing contexts as a simple array CX (1,2,3,4,…n) and assigning individual facts to contexts (water belongs to contexts 2, 17, 43, 156, 287, and 344) is not sufficient. The properties associated with water will have different weights—different relevancies—depending on the context.

Machine learning systems also need a mechanism for recognizing contexts (it would not do for a general purpose machine learning system to respond to a fire alarm by beginning to bake bread) and for following changes in context without becoming confused. Additionally, contexts themselves are hierarchical; if a person is driving a car, that cognitive task will tend to override other cognitive tasks, like preparing notes for a lecture. Attempting to switch contexts in the middle of driving can be problematic. Some contexts, therefore, are more “sticky” than others, more resistant to switching out of.

A context-based machine learning system, then, must be able to recognize context and prioritize contexts. Context recognition is itself a nontrivial problem, based on recognition of input the system is provided with, assignment of that input to contexts, and seeking the most relevant context (which may in most situations be the context with greatest overlap with all the relevant input). Assigning some cognitive tasks, such as diagnosing an illness, to a context is easy; assigning other tasks, such as natural language recognition, processing, and generation in a conversation, to a context is more difficult to do. (We can view engaging in natural conversation as one context, with the topics of the conversation belonging to sub-contexts. This is a different approach than that taken by many machine conversational approaches, such as Markov chains, which can be viewed as memoryless state machines. Each state, which may correspond for example to a word being generated in a sentence, can be represented by S(n), and the transition from S(n) to S(n+1) is completely independent of S(n-1); previous parts of the conversation are not relevant to future parts. This creates limitations, as human conversations do not progress this way; previous parts of a conversation may influence future parts.)

Context seems to be an important part of flexibility in cognitive tasks, and thinking of information in terms not just of object/descriptor or decision trees but also in terms of context may be an important part of the next generation of machine learning systems.

Sex tech: Update on the dildo you can feel

A few months back, I wrote a blog post about a brain hack that might create a dildo the wearer can actually feel. The idea came to me in the shower. I’d been thinking about the brain’s plasticity, and about how it might be possible to trick the brain into internalizing a somatosensory perception that a strap-on dildo is a real part of the body, by using sensors along the dildo connected to tiny electrical stimulation pads worn inside the vagina.

It’s an interesting idea, I think. So I blogged about it. I didn’t expect the response I got.

I’ve received a bunch of emails about it, and had a bunch of people tell me “OMG this is the most amazing thing ever! Make it happen!”

So I have, between work on getting the book More Than Two out the door and preparing for the book tour, been chugging away at this idea. Here’s an update:

1. I’ve filed for a patent on the idea. I’ve received confirmation that the application has been accepted and the process is started.

2. I’ve talked to an electronics prototyping firm about developing a prototype. Based on feedback from the prototyping firm, I’ve modified the initial design extensively. The first version I’d thought about was based on the same principle as the Feeldoe; the redesign uses a separate dildo and harness, with an external computer to receive signals from the sensors in the dildo and transmit them to the vaginal insert. The new design looks, and works, something like this. (Apologies for the horrible animated GIF; art isn’t really my specialty.)

3. The prototyping firm has outlined a multi-step process to develop a workable, manufacturable device. The process would go something like:

Phase 1: Research and proof of concept. This would include researching designs for the sensors on the dildo and the electrodes on the vaginal insert. It would also include a crude proof-of-concept device that would essentially be nothing more than the vaginal insert connected to a computer programmed to simulate the rest of the device.

The intent at this stage is to see if the idea is even workable. What kind of electrodes could be used? Would the produce the right kind of stimulation? How densely arranged could they be? How small could they be? Would the brain actually be able to interpret sensations produced by the electrodes in a way that would trick the wearer into thinking the dildo was a part of the body? If so, how long would that somatosensory rewiring take?

Phase 2: Assuming the initial research showed the idea to be viable, the next step would be to figure out a sensor design, fabricate a microcontroller to connect the sensors to the electrodes, and experiment with sensor design and fabrication. Would a single sensor provide adequate range of tactile feedback, or would it be necessary to multiplex several sensors (some designed to respond to light touch, others to a heavier touch) together in order to provide a good dynamic range? What mechanical properties would the sensors need to have? How would they be built? (We talked about several potential designs, including piezoelectric, resistive polymer, and fluid-filled devices.) How would the sensors be placed along the dildo?

Phase 3: Once a working prototype is developed, the next step is detail design and engineering. This is essentially the process of taking a working prototype and producing a manufacturable product from it. This includes everything from engineering drawings for fabrication to choosing materials to developing the final version of the software.

So. That’s where the project is right now.

The up side? I think this thing could actually work. The down side? It’s going to be expensive.

I have already started investigating ways to make it happen. If we incorporate in Canada, we may be eligible for Canadian financial incentives designed to spur tech research and development.

The fabricating company seems to think the first phase would most likely cost somewhere around $5,000-10,000. Depending on what’s learned during that phase, the development of a fully functional prototype might run anywhere from $50,000 to $100,000, a lot of which hinges on design of the sensors, which will likely be the most challenging bit of engineering. They didn’t even want to speculate about the cost of going from working prototype to manufacturable product; too many unknowns.

I’m discussing the possibility of doing crowdfunding to get from phase 2 to 3, and possibly from phase 1 to 2. It’s not likely that crowdfunding is appropriate for the first phase, because I won’t have anything tangible to offer backers. Indeed, it’s possible that I might spend the initial money and discover the idea isn’t workable.

Ideally, I’d like to find people who think this idea is worth investigating who can afford to invest in the first phase. If you know anybody who might be interested in this project, let me know!

Also, one of the people at the prototyping company suggested the name “Hapdick.” I’m still not sure how I feel about that, but I do have to admit it’s clever.

Want to keep up with developments? Here’s a handy list of blog posts about it:
First post
Update 1
Update 2
Update 3
Update 4
Update 5
Update 6
Update 7
Update 8
Update 9