# Interactive math textbooks

There is no excuse for Ron Larson‘s Calculus, the textbook I used in high school. It’s over 1,000 pages long and it’s printed on paper. This may have been acceptable in 1998 when it was first printed, but today I am amazed that it remains in print. That’s because textbooks should be electronic and interactive.

You have to be suspicious of exisitng “interactive” math content, because it may be interactive in a very shallow sense. For example, if you get a hard question wrong then it shows you an easier question. What I’d like to see are interactible examples and figures: Move a point around on the figure and see how things change in real-time.

Strom et al. have done a very good job of this with Immersive Math, an interactive linear algebra textbook. (A paper textbook cannot update its figures in real-time.) They also have hover-tips for referenced theorems and definitions, which is a nice touch. (In a paper textbook you’d have to flip back.)

I made my own demo for solids of revolution, a difficult topic for many students. You can move a slider to see the differential volume element change. But you can also hover over a term, like $dA$, in the equations to highlight the geometrical interpretation corresponding to the term. Click the animation to be redirected to the demo and try it yourself.

# Delivering bad news in O(N) time

I’ve invented a way to break bad news gradually, instead of all at once. Suppose there is a big question—“Are you breaking up with me?” or “Do I have hepatitis, Doc?” The traditional algorithm is decidedly O(1); the girlfriend or the doctor simply says “yes” or “no,” and the news is broken. It would be nice if we could delay the news, so that the answer became gradually more clear as time passed. Here’s a procedure to do just that.

At each timestep, the doctor (say) flips a coin and hides the outcome from the patient. If it is heads, he simply says “heads.” If it is tails and the patient has hepatitis, he says “heads.” If it is tails and the patient does not have hepatitis, he says “tails.”

Let’s analyze this from the patient’s point of view, supposing that both answers start out equally likely in his mind. That is, $\mathrm{P(hep)}=\mathrm{P(no\ hep)}.$ Suppose there have been N timesteps. If the doctor ever says “tails,” then the patient knows he’s in the clear. So the interesting question is how the patient’s degree of belief changes when the doctor has said “heads” every time for N timesteps.

Using Bayes’s theorem and some algebra, you can show that $\mathrm{P}(\mathrm{hep}|N) =\Big[\mathrm{P}(N|\textrm{no hep})+1\Big]^{-1}.$ In order to get N “heads” responses given no hepatitis, the coin would have to land heads-up N times. And we know that has probability $(1/2)^N.$ After a line of algebra, we get

$\mathrm{P}(\mathrm{hep}|N) =\frac{2^N}{2^N+1}.$

This approaches 100% as N tends toward infinity, which is what we expected. On the other hand, if the patient doesn’t have hepatitis then we expect a “tails” to come up after only 2 timesteps.

# Secure communication through CIA-infected devices

## The problem

WikiLeaks recently published documents detailing CIA attacks on common smartphone operating systems, including those on Samsung, Google, and Apple devices. WhatsApp and other “secure messaging apps,” it turns out, are not secure at all. The reason is that if the phone OS is itself compromised, nothing on the phone can be secure. It doesn’t matter how good your app’s encryption is—if the CIA can read everything on my phone, then that includes unencrypted plaintext and private encryption keys.

The situation appears hopeless. For one thing, our devices are not secure. Furthermore, who’s to say the cell phone companies won’t voluntarily give the government your data, even if the operating systems themselves are fixed? If you want secure communication, it seems the only way to do it is to build your own cell phone, and then build your own network of cell towers.

## My solution

Sending secure messages over untrusted channels is basically a solved problem. Encrypt the message with RSA and sign it with DSA, for example. (These, and similar algorithms, will probably be broken by quantum computers. But as far as we know, that hasn’t happened yet.)

What makes the situation more interesting is that the broadcasting device itself can no longer be trusted. So, where does that leave us? Assuming I can’t patch the phone, I need a new device.

The new device would:

• randomly generate keys
• accept plaintext input from a keypad
• encrypt messages with a private key
• decrypt messages with a public key

Since we still want to use the phone to send and receive public keys and encrypted messages (ciphertext), we would need to transmit these back and forth between the phone and the device. I drew a schematic:

Fig. 1 By hiding the plaintext and private key from CIA malware on Samsung and Apple devices, we can broadcast messages securely from these infected devices.

There are a few points you’d have to consider to make this thing work. After all, if they can hack my smartphone, why can’t they hack this thing?

First, it would have to be completely open-source from the circuitboard up. That way, anybody could check for security vulnerabilities on their own.

Second, it would have to be simple. This way, a single user could understand the entire system and convince himself that there were no holes. Security flaws emerge when a product becomes too complicated for an individual engineer to understand in its entirety. You can’t hack a toaster! But you can hack an operating system, because it’s got a lot of “moving parts.”

Third, you would have to ensure that the encrypting device could not be infected via the connection to the smartphone. I would be wary of complex protocols like USB. In fact, one could go so far as to send and receive information over the headphone jack. (Microphone for output; left or right channel for input; ground for ground.) That way, you know that only data bits are being sent, not commands or metadata or any other crap. Unless I am mistaken, the only potential vulnerability would be buffer overflow attacks—and you can avoid those if you’re careful.