Talk Funnel

This message popped into my email inbox today:

A few points worth mentioning:

• The [SPAM] tag was not added to the subject header by any software on my end. As near as I can tell, it was either put there by the spammer’s own email server, or added manually.
• The particular inbox to which the message was addressed is protected by a server-side whitelist service (SpamArrest). For the message to get through, somebody has to go to the trouble of explicitly confirming that they’re really a human and put themselves on the approved list. The sender did this.
• The same message has been sent several times under different email addresses. Every time, I ban the address and a while later it makes its way again with a new sender address (which has to be manually confirmed with SpamArrest, again).
• I feel bad for the ‘real’ Dr. Lulu Gwagwa of South Africa, who appears to be a most accomplished investment banker.

For some reason, the perpetrators of this message are really determined that this message get through and a lack of response (or continuous placement on the ban filter) doesn’t seem to deter them. That they consistently confirm their own address through SpamArrest tells me that they are not exactly high-volume ’shotgun’ spam traffickers. Those people rarely provide a working reply address.

On the other hand, I have to admit that opening with an apology and the fact that they admit they got the email while doing a ‘random transaction’ on the Internet shows refreshing candor.

Sadly, I am forced to ban the sender once again, as much as I appreciate the effort.

Share This

A fascinating chart showing the origin of most Spam on the Internet.

Share This

Share This

Holy crap!

French author Michel Houellebeck gets slammed hard by, of all people, his own Mother (more here).

Wouldn’t it be funny if she ended up with the Prix Goncourt instead of the acolyte of modern nihilistic French literature? The lesson: don’t put thinly veiled insulting caricatures of your Mom in your writings. She probably has more dirt on you than anyone else.

On an unrelated note, I’d like to take this opportunity to wish my mother an early Happy Mother’s Day and tell her what a fantastic, great individual she is…

Share This

Jeff Jarvis ponders whether Insurance is impervious to social reinvention. I don’t agree, but I think it’s going to take some pretty big thinking, a major set of cojones, and a fair bit of social engineering.

A few years ago, I spent a fair amount of time working on a desktop healthcare application, with the idea being to let people take care of their own healthcare needs. After a couple of years of research and development, I ended up mothballing the system after realizing that the only way to get something like that to work was not to tackle a small piece of the process (the user’s health records) but the larger, systemic problem of health insurance. Incidentally, it is for this very same reason that I think half-baked efforts like Google Health and Microsoft HealthVault are doomed to irrelevance.

Now, I don’t make any claims to being an expert in insurance or healthcare. But I’ve been cursed with a healthy dose of curiosity and a background in designing and building complex systems, which qualifies me to do a lot of standing on top of hills and looking for patterns. It turned out that most of my two years of work on the software was spent studying the healthcare and insurance industry, instead of coding.

After all that time and effort, I finally came to my senses and realized that tackling the healthcare system was just too daunting a task since it required aligning the interests of ALL parties involved in the chain including insurers, doctors, employers, etc. all the way down to the individual. So I mothballed the project and went off to write fiction and start a family. But the problem has always nagged at me. There’s a little voice in my head that keeps saying: There must be a better way.

My good friend and business partner Mitch Ratcliffe recently went through some experimental surgery (that thankfully seems to have worked). He’s written about it here and his conclusion was that there is a “need for a new economics in medical care.”

I couldn’t agree more. But how do you tackle something as unwieldy as the insurance industry (and its medical offshoot, the healthcare system).

A hint comes from a comment made by Seth Godin in response to Jeff’s post: you have to think big. The only way to do Insurance 2.0 (including healthcare) is to rethink the whole process, free of all the self-interested legacy cruft that has been built into and around the system.

Yes, now is a good time to get those eyes rolling. Contrary to what some might assume, I’m not one of those technology über-alles types. As far as I’m concerned, technology is — as the kids like to say — our bitch. Its purpose is to serve us, not the other way round. Nor do I subscribe to the baby/bathwater theory — that everything is broken and needs to be thrown out.

But please, indulge me for a moment.

The way risk is currently calculated is primarily static and completely opaque to the consumer. Insurance companies hire an army of actuaries who come up with risk tables for a variety of situations and create complex mathematical systems to help mitigate it. These metrics often take into account some key milestone events in a person’s life (i.e. if you get married, move, change jobs, fall ill, etc.) but do not allow for mitigating circumstances (like the death of a parent) nor do they require any sort of active involvement or participation by the consumer.

By and large, you get quoted a rate, you pay your premium without really knowing how or why any of it works. All you know is that if you make a claim, your rates will go up. The insurance company is going to do everything in their power to make it hard for you to pull money out and everything (including hardball legislation) to make it difficult for you to use the benefits. Your interest as a consumer of insurance and that of the insurer are in direct conflict with each other (in computer network parlance, it’s a master-slave relationship.) How your behavior affects others (or theirs yours) doesn’t even enter into it, even though technically you are all in the same risk pool together. It’s as if you live in a silo.

It also makes for a complex, top-down system of rules and risk calculations — most of which are designed to push the risk back down onto the insured and the money up toward the insurer. And the whole edifice comes tumbling down when you get large systemic catastrophes, like floods, wars, or epidemics.

Since we’re complaining about the system, what else is wrong with it? Plenty. The underwriting rules are almost never disclosed completely (not that too many people would care) and any attempts at making a claim is often met with a flurry of complex paperwork designed to slow the process down, to dissuade the (busy) consumer from ever again wanting to make a claim again. As Jeff calls it, it’s a sucker’s bet — in more ways than one.

So what’s the solution? More government regulation? Applying the Web 2.0 salve? Actually… neither.

To get a better picture, we have to engage in my favorite activity of zooming up into birds-eye range and looking at the whole system. The insurance system (if it can be called that) is a series of complex, interlocking, top-down subsystems, with various balkanized pools of information, and players whose interest (and power) is served by keeping a chokehold on that information. By design, it’s complex and anyone who gets too close to it will inevitably get swamped with information overload and quickly back off. Those who don’t (like a certain former First Lady) will likely get singed in the political heat (and maybe start imagining incoming sniper fire

The alternative to a complex centralized system is often a simple, decentralized system that applies rules recursively. Think P2P, fractals, or human cellular biology.

The Web 2.0 version of insurance (again, including healthcare) would have to start with a simple, easy to understand mechanism that anyone can use to assess the risks and the costs. It would have to be dynamic, transparent, and let you know exactly where you stand so you can make informed life decisions. It would have to take into account every other participant in the risk pool and encourage open communication. It should be understandable by anyone, and when applied collectively, provide the best answer to global risk mitigation.

In other words, it will have to be open and transparent. Yes, it sounds impossible, but the alternative is to replace one complex system of knobs and levers with another one. I am convinced that the solution is in simple, recursive, self-organizing systems. I have some ideas as to how this could work, but this is the sort of thing best tackled (and vetted) by a group of interested individuals dedicated to the art of simplification.

There’s another thing to consider: as commenter Uncle Fester says in response to Jeff’s post, there are HUGE regulatory and financial barriers to creating new insurance mechanisms.

First, instead of calling it insurance let’s call it something completely different (Lifecare, for example). This is not just semantic sleight-of-hand. The term ‘insurance’ comes with a lot of baggage which can get one bogged down in regulation and litigation for a lifetime. Second, to make it work so it becomes something that can be trusted (that it’ll be there in times of need) and get large-scale adoption, it’ll have to align the interests of all beneficiaries — in this case, individuals, businesses, government regulators, AND … (wait for it) insurance companies (!!!)

How can this work? Why would any insurance company want to participate in a competitive scheme that threatens their core business?

The problem is that the whole insurance edifice (including healthcare and pension plans) is a Ponzi scheme. As long as there is new, low-risk money coming into the system, the high-risk ones can be covered. The difference, however, is that investors don’t really cash out — they die, or move their business elsewhere, so they have to never be paid off. Most people don’t need healthcare when they’re young and spend most of their lives accident-free. The majority of the time, they automatically pay into the plan. The earlier they die (or get kicked out of the risk pool) without using expensive resources, the better off the scheme will be, having taken all the premiums and paid out relatively little of it.

The way to bootstrap a new Insurance 2.0 is to start by taking the highest risk policies off the hands of current insurers (along with a decent amount of cash for doing them the favor) and bootstrapping a distributed risk management system into place. Who are these high-risk people? For starters: sub-prime mortgages, pretty much any auto driver in Southern California :-), and pension-fund members on the books of large corporations. These are all high-risk, low-reward insurance policies that are liable to cost the insurers billions in years to come.

By taking these groups and putting them into a social/distributed scheme, you get to battle-test the system and make sure all the rules are fairly applied. Sure, there will be initial falterings. But over time, a self-regulating system will develop the right mix of complexity vs. fairness and provide a more balanced mechanism than what we have today.

This is the alignment of interests I earlier referred to: insurance companies (with bad bets on their books), corporations (with increasing healthcare and pension costs), government agencies (who may get saddled with the costs as an insurer of last resort), and the individuals themselves (faced with no coverage) will all be interested in seeing this experiment work.

It will require a large pool of startup capital and easing of regulations, but if it works, it could revolutionize the way liability insurance, healthcare, and pension plans operate.

As Seth Godin says: Think Bigger, Jeff!

But start by thinking small (and recursive).

Share This

Image via Wikipedia:

There’s a lot of symbolic significance (in many different walks of life) that you can read into this one picture. In your own field of work, are there situations that can be described in this way?

Share This

“Fat Elvis or Thin Elvis stamp? Let’s flip a coin. Hey, I know…”

Via Photo Basement

Share This

Image: Wikipedia

In the early 1990’s, I got involved with a local arts group called George Coates Performance Works (GCPW). The productions combined opera, theater, music, live projection, videoconferencing, and a lot of new technology — mostly donated by companies like Apple and SGI, but also some lab oddities scavenged around Silicon Valley.

In one of the more popular pieces — Box Conspiracy — an actor stood on stage and used a pen-tablet to interactively control a large ‘all-seeing’ 3-D eye that was projected on the screen behind him. Making this work involved hooking up a prototype pen tablet to a wireless modem that was connected to an SGI workstation back in the control room. The SGI used the pen inputs to drive a custom animation program that generated left-eye/right-eye images in 3D. This was then projected onto the screen behind the actor and the audience (wearing polarized 3-D glasses) got to experience the synthesis of live and generated worlds in real 3-D space.

This was way before pen tablets and way, waaaaay before wireless was ubiquitous. GCPW productions were often a combination of artistry and super-high tech. On any given day, opera singers and actors mingled with 3-D designers from LucasArts and NASA engineers. It was an interesting experience.

From a technical point of view, it all had to be hand-rigged, with custom client, networking, and 3-D rendering software, along with private protocols synchronized across multiple platforms. The effect was pretty cool and the show ended up being pretty popular (less due to the special effects, I think, than its timely lampooning of the ‘5000 interactive TV channels’ meme).

The pen-tablet interface always bothered me a little. The thing we really wanted to do was to use the actor’s body as the input to the software and synchronize the movement with the live 3-D scene projected around him. There were a number of technical challenges. The first was how to establish a person’s body position without hindering their movement.

Once we had that, we would need to figure out where the arms and feet stood relative to the trunk. There were a number of Rube Goldberg devices out there, mostly for gaming and 3DVR applications that involved wearing body-suits or harnesses, with heavy wires tracking behind them (the sort of technology later used to generate the fluid motions of the Gollum in Lord of the Rings). The state-of-the-art in motion tracking back then was the Data Glove. Full-body tracking was a pretty tall order, but it seemed like it was an easier problem than tackling the body’s position.

The first step was to see if we could snip the wires. The wireless modem we used with the pen tablet was a lab prototype donated by a hardware vendor (can’t remember their name, but I don’t think they ever commercialized it). It was pretty lightweight and could be clipped to the waist and it could run for a few hours on a single battery charge. All it did was act like a standard RS-232 serial port (remember those?) so you could use it like a pretty long cable and transmit simple position data. The software at the other end could read it and use it to render the imagery.

But then how to establish the actor’s position and movement?

The solution I ended up pursuing (but ultimately abandoning as unworkable) was to combine a gyroscope with a set of accelerometers and a touch-sensor. The touch sensor could establish a ‘home’ position on the stage while the gyroscope and accelerometer (carried by the actor) could record relative position and motion from that point on. A small computer (the pen-tablet?) could gather the data and transmit it through the modem back to the SGI. The whole contraption could be fitted inside a harness or small backpack.

I tried finding out as much as I could about gyroscopes and accelerometers (this is pre-Google). Not much there. Fortunately, there was a big electronics and embedded system trade conference coming up in San Jose, so I headed down to see what I could find.

The problem that ultimately sank the whole plan was a condition called Gimbal Lock. A gyroscope is made of a rotor spinning inside three inter-locking rings, each connected to another via a tiny pin. Sensors on each ring can calculate relative motion in X/Y/Z (aka pitch, roll, and yaw) coordinates. The problem is with those tiny pins. If you move the whole contraption far enough, the spinning rotor eventually comes pretty close to where the pins sit. If you’re not careful and the ring actually hits the pin, the angular velocity of the rotor will send the whole thing spinning around wildly and everything goes bat-shit crazy.

In airplanes, where this technology was mostly used, gyroscopes were often used as part of an Inertial Navigation System and connected to the auto-pilot. If the plane made a sudden motion and the gyro hit Gimbal Lock, it was considered a Very Bad Thing.

The only way to get around Gimbal Lock was to shut the whole gyro down, wait until it stabilized then spin it back up again — a process that could take several minutes since the gyros often ran at thousands of RPMs. There were some techniques to work around this problem (like using a fourth gimbal) but this was not available in the smaller, low-powered gyroscopes.

At the conference, I remember asking several vendor reps if they could think of a solution (the booth staff in these types of conferences were always heavy-duty PhDs who could actually answer technical questions). They would ask me what the application was. I remember explaining what I was trying to do, fully expecting them to gently scoot me away to make room for the serious customers. Amazingly, they would all get excited — I like to think it reminded them why they got into engineering in the first place.

They’d sit down with pen and paper and try in-earnest to tacke the problem. Product manuals would be consulted. Charts and scientific calculators would be whipped out. But alas, the universal conclusion was that given the state of the technology at that time, there was no way to put together something that was a) cost-effective, b) not susceptible to periodic locking, c) could be carried by a human being (even in a back-pack), or d) all of the above. But they all agreed that it was a very unique application, seeing as how most of their customers bought their hardware for use in spaceships.

After a whole day of this I gave up on the idea and eventually went with the pen-tablet set-up.

What made me reminisce about all this was my tinkering today with the solid-state accelerometer built into the iPhone. It can tell when you’re moving it around all three (X/Y/Z) axes and has pretty good resolution. The iPhone also has built-in WiFi, so two things out of three I needed to solve that problem — all of which would require a backpack and a sturdy back — are built into this little hand-held device.

The only thing missing is a solid-state gyroscope and a wayback machine so I can go back and use it on that stage.

Share This

Photo via CNET

Looks like a lot of people are getting the so-called iPhone developer program ‘rejection’ letters from Apple.

John Gruber points out that developers can already write applications with the existing SDK. But there’s a chain-reaction that emanates from this rejection / delay / waitlist letter (which I got too, for the record). See if you’re not in the ‘full’ developer program, you don’t get a signed certificate.

No signed certificate, no way to upload your app to the iPhone via XCode. No way to upload your app, no way to test it if you are using features not supported in the simulator (I won’t list them since the SDK is issued under NDA, but there are more than a few — including a lot of features game developers would need). In other words, the certificate isn’t just so you can upload your creation to the App Store in the June time-frame.

It’s also necessary to start basic development today.

The only reason I can think of for Apple to have done this is to prevent the flood of apps they’re going to receive down the line, all clamoring to be reviewed and approved for sale on the App Store. But doing it in this way means a lot of developers can’t even get going until June (or whenever the SDK gets out of beta) and that puts them in a bad position competitively against those who do get the certificates. Who knows? It may even create a gray-market in certificates (EBay anyone ;-))

If flood-control is really the reason behind Apple’s move, they can still accomplish it at the point of submission of the app for approval — and while they’re at it explain the rules for who can get onto the store, how long the wait might be to get approved, how does an app get onto the ‘featured’ page, etc. But they really ought to go ahead and issue the certificates now so people can start their development work.

I personally went through the certificate signing process with Thawte a couple weeks ago to get one for an Adobe AIR application. It took about a week and cost $299/yr. Thawte already sells signed certificates for Mac-OS (alongside those for Java, Microsoft, Netscape, VBA, and Adobe). There’s no reason why Apple can’t separate ‘app-development’ certificates from ’sell via App Store’ certificates.

At this point, those developers wanting to use non-simulated/phone-only features and who don’t want to wait have no choice but to go the jailbreak/open-source toolchain route (making Jonathan A. Zdziarksi, the author of iPhone Open Application Development the luckiest / unluckiest / luckiest technical author around).

The trouble is that Apple’s released SDK headers are far more restrictive than what jailbreak tools allow, and finished apps may not use any undocumented APIs. For example, people have ported a ridiculous number of app development tools — Python, Ruby, Apache web-server (!) — to run on a jailbroken iPhone. None of these are permitted under the rules of the official SDK — making it a safe bet that jailbreaking will continue apace even after the SDK is launched.

Remember, if you’re a developer and have to get going on a jailbroken system:

1. You don’t get to use all the cool XCode tools.
2. You have to constantly double-check to make sure you don’t use features not officially released in the SDK, and
3. You may want to stand in line to get your finished application into the App Store approval hopper early (if and when Apple releases those signed certificates).

It looks like there may be a long line of developers forming in the back of the App Store pretty soon. But then again, if you’re an iPhone fan, you’re probably used to standing in line…

Update: Ars Technica misses the point of the delayed/AWOL certificates. They’re not just needed for deployment. For many people they’re needed to start development.

Here’s a solution: Adobe AIR allows self-signed certificates. They’re useful to get things going, but can not be used for deployment. This is probably the way to go for Apple. Put out a self-cert tool for everyone and get out of the way. Then put up BIG warning signs in the 2.0 firmware whenever someone tries to run a self-signed application. That ought to get things going.

Share This

Yesterday, I speculated as to how Apple might try to manage the flow of iPhone apps wanting to make their way onto the App Store.

Seems like one way to do it is to throttle it at the inlet.

Yeah, that’ll keep the developers enthused.

Share This