Thursday, February 28, 2013

A simple solution to credit card fraud, part 4: A primer on elliptic curves

(This is part 4 of a series.)

This post will be a geeky digression from the main narrative, because jonny said he wanted to hear more about elliptic curves.

Up-front disclaimer: I am not an expert on elliptic curves, and I wrote this post in some haste.  It's possible I made some mistakes in some of the equations.  Don't rely on what you read here for anything mission-critical.

The key (no pun intended) to cryptography is finding hard mathematical problems.  A "hard problem" is a term of art: it means a problem for which there is no known solution that is significantly less work than brute force.  The hard problem that RSA is based on is finding the factorization of the product of two large primes.  The hard problem that elliptic curve cryptography is based on is something called the discrete logarithm over point multiplication.  The purpose of this post is to explain what that means.

We'll break this down into two parts.  First, discrete logarithms.  Recall that an ordinary logarithm is the inverse of exponentiation.  If X raised to the power of Y is Z, then Y is the logarithm of Z base X.  Notice that the form of this definition is the same as the form of more familiar concepts like difference and quotient.

If X plus Y is Z, then Y is the difference of Z and X.
If X times Y is Z, then Y is the quotient of Z and X.
If X raised to the power of Y is Z then Y is the logarithm of Z base X.

A discrete logarithm is just like a regular logarithm, except that all the mathematical operations are done modulo some integer Q, which is typically a very large prime number.  Every time you add or multiply, you divide the result by Q and take the remainder.  (Another way to think of this is that all intermediate results are stored in a register than rolls over at Q, and overflows are ignored.)  A modulo B (often abbreviated A mod B) is the remainder when A is divided by B.

For the sake of illustration, let's pick Q=13.  (In practice Q would have hundreds of digits.)  And let's pick two numbers out of a hat, say, 7 and 9.  The sum of 7 and 9 is 16, so the sum of 7 and 9 mod 13 is 3.  The product of 7 and 9 is 63, so the product of 7 and 9 mod 13 is 11 (because the remainder when you divide 63 by 13 is 11).  7 raised to the 9th power is 40353607, which leaves a remainder of 8 when divided by 13, so the discrete logarithm of 8 base 7 (mod 13) is 9.

A discrete logarithm over an elliptic curve is just like an ordinary discrete logarithm, except that regular numerical addition is replaced with a mathematical operation called point addition over an elliptic curve.  An elliptic curve is just a regular old curve of the sort you learned to graph in high school algebra class.  The equation of an elliptic curve looks like this:

y^2 = x^3 + A*x + B

where A and B are constants.  The shape of this graph is not particularly important, but if you're interested you can find examples here.

Elliptic curves have the useful property that if you draw a line between any two points on the curve, that line is guaranteed to intersect the curve at exactly one additional point.  (That's not quite true, but a good enough approximation for now.  I'll fill in the actual details later.)  Using this fact, we can define an operation called point addition: to add two points, draw a straight line between them.  The sum is the third place where this line intersects the curve.  (Actually, the sum is this point with the Y coordinate multiplied by -1, but you can ignore this for now.  It makes an interesting exercise to figure out why the definition of point addition has this peculiar feature.)

Of course, you don't have to do this operation geometrically.  You can do it mathematically as well.  And if you do it mathematically, you can replace all the mathematical operations on real numbers with discrete operations on integers modulo Q, and all the results remain the same.

For the rest of this discussion, all arithmetic is done with integers modulo Q.

I've glossed over two details that you can safely ignore for now, but I'll describe them here just for completeness, because if you go read the literature on elliptic curves you will encounter these terms.

First, if you draw a line between two points on the curve with the same X coordinate, then this line does NOT intersect the curve.  To fix this, we add a conceptual "point at infinity" and define the sum of two points with the same X coordinate to be this point.  (To any mathematicians reading this: yes, I know this is not how the point at infinity is actually defined.  I'm trying to keep this simple.)

Second, if you try to add a point to itself you don't have two discrete points to define a line.  In this case we draw the line tangent to the curve at this one point, and find the second point where this tangent line intersects the curve.  The math is a little different in this case, so adding a point to itself is called point doubling instead of point addition.

If you're having a hard time visualizing all this from my description here are some pretty pictures.

So now we have this abstract mathematical "point addition" operation, and it turns out that this operation has the same algebraic properties as regular old addition: it is commutative (P1+P2 = P2+P1) and associative ((P1+P2)+P3 = P1+(P2+P3)).  It has an identity element (which turns out to be the "point at infinity").  So we can use this operation as if it were addition and define point multiplication of a point P by a number N in the usual way, as P added to itself N times.

We have to stop there.  We can't go on to define "point exponentiation" because we have a "type mismatch" error.  Exponentiation is normally defined as a number multiplied by itself N times.  But we can't multiply a point by itself, we can only multiply a point by a number.  But that turns out to be good enough, because the inverse of point multiplication turns out to be a Very Hard Problem.  Mathematicians call it a discrete logarithm even though it would more properly be called a discrete quotient.

There is a clever trick that allows the product of a point P and a (large) number N to be computed very efficiently.  It is in fact the exact same trick that allows you to multiply two ordinary numbers efficiently.  But there is no known way to solve the inverse problem efficiently if you're using modular arithmetic.  This is what makes point multiplication a useful building block for cryptography.  (Note: this is true for modular exponentiation of ordinary numbers as well, but not for modular multiplication of ordinary numbers.  There are ways to compute modular multiplicative inverses efficiently.)

As an example of how we can use point multiplication, consider the problem of key exchange.  You want to use an insecure communications channel (like the Internet) to send secret data to Bob.  You can encrypt the data, but then you have to somehow get the encryption key to Bob so he can decrypt the data.  You can do this with a technique called Diffie-Hellman key exchange (after the two people who invented it).  You and Bob each pick a large random number.  Say you pick N1 and Bob picks N2.  You also agree on an elliptic curve and a starting point P (called the "base point").  You compute P*N1 and send the result to Bob.  Bob computes P*N2 and sends the result to you.  Now you compute (P*N2)*N1 and Bob computes (P*N1)*N2.  Because point multiplication is commutative and associative, the results will be the same.  But an eavesdropper who only knows P*N1 and P*N2 cannot compute P*N1*N2 unless he knows N1 or N2, and to find either of those numbers he has to solve the discrete logarithm problem.  In this scenario, N1 and N2 are the secret keys, and P*N1 and P*N2 are the public keys.  So P*N1*N2 is a shared secret that you and Bob and use to encrypt data to send to each other.

Using elliptic curves to produce digital signatures is a little more involved, but here's the intuition behind it: suppose you do a Diffie-Hellman key exchange with Bob.  You send Bob P*N1.  But that doesn't prove that you know N1.  You might have obtained P*N1 by eavesdropping on someone else.  How can you prove to Bob that you actually know N1?  One way is for Bob to encrypt a message using the (supposedly) shared key P*N1*N2 and ask you to decrypt it and report the result.  If you can decrypt it, that proves you know N1, because that's the only way you could have computed the decryption key P*N1*N2.

That proves you know N1 to Bob, but what if you want to be able to prove you know N1 to anybody?  One possibility is to do Bob's side of the protocol for him: pick a random message M and a random private key N2 and publish the following:

1.  M
2.  N2
3.  P*N1 (your public key)
4.  M encrypted with the "shared" key P*N1*N2

Because you have published P*N1 and N2, anyone can now compute P*N1*N2.  So anyone can decrypt the encrypted message and verify that it matches M, which proves that you must have known N1.

That's a good start, but this version of the protocol has a fatal (and rather obvious) flaw.  See if you can find it before reading on.

The problem is that there is no way to know that the public key you published is in fact the result of *you* computing P*N1.  You could have obtained P*N1 by eavesdropping on someone else's Diffie-Hellman key exchange.  You could even have just picked a random number.  The only reason that the Diffie-Hellman protocol works is that both N1 and N2 are secrets held by two different people.  Diffie-Hellman only allows you to prove your knowledge of N1 to someone who knows N2 and who knows that you do not know N2.  So if you pick N2 the protocol collapses.

How do we fix this?  We have to roll N1 into the computation somehow in a  way that the result has the following properties:

1.  The result could only have been computed by someone who knows N1
2.  The result is verifiable by anyone
3.  The result does not reveal N1

We do this by choosing a random "message" (let's called it M) and "encrypting" it in two different ways that can be combined in a way that only works if the encryption was done with knowledge of N1.  I put "encrypting" in scare quotes because at this point we're not really encrypting, just slicing-and-dicing in a way that can't be easily undone.

I'm going to change notation a bit to make what comes next a little easier to follow.  What I have been calling N1 to now I am now going to start calling SK (for Secret Key).  What I have been calling P, I am now going to start calling BP (for Base Point, a constant, publicly known common starting point on whatever elliptic curve we are using).

Recall that our strategy is to slice-and-dice a random number M in two ways so that the results can be combined in a way that works only if they were produced with knowledge of SK.  First we compute our public key, PK, just as we did with Diffie-Hellman key exchange, but using our new notation:

PK = BP*SK (formerly known as P*N1)

Note that PK is a point on the curve, not a number.

Next we compute:

R = XC(BP*M)
S = SK*R/M

where XC(P) means the X coordinate of a point P.

The signature is the pair (R,S).  (Note that "dividing by M" really means multiplying by the multiplicative inverse of M (mod Q).)

To verify this signature, compute XC(PK*R/S).  If the signature is valid (i.e. was computed by someone who knows SK) this will be equal to R.  Verifying this is elementary algebra:

PK*R/S = (BP*SK)*R/S = BP*(SK*R)/(SK*R/M) = BP*M

So XC(PK*R/S) = XC(BP*M), which by definition is R.  QED.

This protocol still has a problem, but it's much more subtle than the problem with the first version we came up with.  For this protocol to work, M has to be kept secret, because if we know M we can trivially recover SK.  (Figuring out how is left as an (easy) exercise.)  So we can prove we know SK, but we can't yet bind that proof to a message (because we have to keep M secret).  To be a useful digital signature scheme we have to be able to associate that proof of knowledge with some known message.  To make this happen we have to tweak the protocol yet again.

At this point the story gets a little more complicated because there are two ways to do this final tweak.  There's the standard way, and there's the Right Way.  It is extremely rare for a deeply flawed standard to get established in cryptography, but in the case of elliptic curve digital signatures it has happened.  So I'll start with the standard way, explain what the flaw is, and then explain the Right Way.

To bind a signature to a document in the standard way we first generate a secure hash of the document, which we will call H.  As before, we also choose a random number M, which again we must keep secret.  We compute R just as before, but change the computation of S like so:

S = (H + SK*R)/M

The signature is the pair (R,S) as before.  The verification step also gets tweaked.  To verify, we compute:

XC((BP*H + PK*R)/S)

and verify that this is equal to R as before.  You can verify for yourself that this works by crunching through the algebra.

The flaw in this scheme is that not only must M be kept secret, but you also have to be very careful never to use the same random M to sign two different messages.  If you have signatures for two different messages generated with the same SK and M values, then you can easily recover SK, the secret key.  This is how the Sony Playstation was hacked.

The way to fix this problem is not to use a random M, but instead to use a hash of the message being signed plus the secret key as M.  This insures that different messages will never be signed with the same M value.  This brilliant trick was invented by Daniel J. Bernstein, commonly known by his initials, DJB.  [UPDATE: I was mistaken, this trick was not invented by DJB, it was invented by George Barwood and John Wigley in 1997.   Thanks to pbsd for pointing that out.]

I really wanted to write about a particular elliptic curve invented by DJB called Curve25519, but I'm running out of steam and I want to post this today, so that will have to wait.  Sorry about all the cliffhangers.

Wednesday, February 27, 2013

A simple solution to credit card fraud, part 3

This is part 3 of a long story.

One of the reasons this story is so hard to tell is that it's hard to know where to begin.  The situation I find myself in today can be traced back at least to 2006, and possibly earlier than that, but does anyone really have the patience to sit through a book-length memoir?  I wouldn't.

So I'll skip 2006 for now (though that makes a good story too, and timely too because that's when I worked with Jody Sherman) and start on March 20, 2008, when I sent out the following fateful email to a mailing list of ex-googlers interested in angel investing and other startuppy things:
I just got back from the Y Combinator Demo Day and there are more promising-looking early-stage startups there than you can shake a stick at.  We don't have enough money to invest in all the ones that looked good to us, which got me to thinking: someone ought to put together a fund or a syndicate so that you could diversify across a fairly large selection of YC startups so that you could diversify without having to invest a huge amount of money.  Is there any interest in this?
There was.  I was soon joined by a dozen other Xooglers, including Brian Singerman who became my co-founder in a small fund that we called XGYC (Ex Googlers investing in Y Combinator companies).  I volunteered to do the administrative work because I was very green and I thought I would learn a lot.  I did learn a lot, including the fact that administrative work sucks.  It's boring and it's repetitive, but it's necessary and you have to pay attention because if you miss a deadline or get something wrong then you have to go back and fix it and it's an even bigger pain in the ass.

By far the biggest PITA was (and remains to this day) actually managing the money.  The mechanisms that we in the U.S. have for moving money around are horribly antiquated, inefficient, and insecure.  I actually started learning this before XGYC, when a six-digit wire transfer was lost for two weeks because the sender had filled out the (paper) transfer form incorrectly.  And when I say lost I mean lost.  No one knew where the money was.  There was no way to track it.  The only reason it was found was because the person who received the money (some random stockbroker) contacted the sending bank and gave it back.  Yes, I know this is hard to believe.  I didn't believe it myself at the time.  Some day, if there's enough interest I'll write up the details.  (I keep telling you this is a long, complicated story!)

Anyway, for a high-tech entrepreneur there are no problems, only business opportunities, right?  I gazed into my crystal ball and saw a day when YC demo days would be much bigger, there would be a lot more angels out there dealing with the exact same problems I was facing, filling out the same forms over and over, dealing with the same accounting and legal BS over and over, and decided that there could be a market for a sort of "angel syndicate in a box" type product.  The idea was to integrate tools to simplify or automate all the standard repetitive tasks that I was doing by hand.  In particular, I wanted to streamline the accounting.  Standard SOHO accounting packages are not designed with investors (or even high-tech startups) in mind.  They're all about managing inventory, accounts receivable, yadda yadda yadda, and their UIs are a disaster.  Five years on and I still can't figure out how to make Quickbooks behave.

The key, it seemed to me, was to integrate the accounting with the money transfer somehow.  One of the biggest problems I was facing managing XGYC was keeping track of who had paid what when, particularly when wire transfers were involved.  An incoming wire would show up on the bank statement without any description of what it was for, only an indication of the bank that sent it.  Sometimes I could figure out what it was based on the amount, but often, particularly at the beginning when the syndicate members were making their capital contributions, there was no way to tell whose money had come in, and I had to send out emails asking people to send me the reference numbers for their transfers.  Later, after we started making money (The fund has done quite well, thank you very much!) I would send out distribution checks and people would fail to cash them.  Don't even get me started about the problems that causes!  (I will probably be writing a future entry about checks and the myriad problems they cause.)

The more I learned about how the financial world works under the hood the more shocked and appalled I became.  The whole system seemed (and still seems) to me like it was being held together with spit and bailing wire.  To this day I am amazed that it works at all, let alone that it works as well as it does, and it does work quite well considering how deeply broken it is.

Still, it was 2008, and there was (and still is) a lot of room for improvement.

I came up with a fairly detailed plan for an integrated banking and accounting service specifically targeted at startup companies and their investors.  I still think this would make not just a viable product, but a kick-ass company that could be the Next Big Thing.  But I gave up on it last March after working on it for three years.  The TL;DR version of why I gave up is that I was never able to find a satisfactory way of moving the money around.

Moving money turns out to be a very complex and subtle process.  It's conceptually very simple, and if you use cash it is very simple: I give you a dollar.  Now you have a dollar more, and I have a dollar less.  Alas, that is where the simplicity ends, because sooner or later that dollar ends up being deposited into a bank.  And that is where all the trouble starts.

(Some people think the trouble starts when you consider a piece of paper to be money in the first place instead of, say, gold, but they are wrong.  This is another tangent that I may write about some day, but for now suffice it to say that very few people actually seem to understand what money is or how it works, including many people who work in the banking industry.  But I'm getting way ahead of myself.)

Don't get me wrong, I think banking is a terrific idea.  The problem with today's banks is not that banking is inherently bad.  Modern technological civilization could not have been built without banks.  The problem with today's banks is that they have forgotten the business which they are supposed to be engaged in, which is to allocate capital and manage risk.  Notice that I said manage risk, not avoid risk.  To the contrary, when the banking system is working properly the banks willingly take on (managed) risk.  But today's banks avoid risk by any means necessary, including fobbing it off on third parties or the government.  This is great for the bank's bottom line, at least for a while, but it's an unmitigated disaster for society.  But again, I'm getting ahead of myself.

My plan was this: for every person or entity participating in my system, I would open an account for them at some bank who would become my partner in this business.  All of the initial capital would flow into this bank by traditional means.  But once the money was in the system, all "in-network" transactions could be conducted by initiating inter-account transfers within that one bank.  Moving money between two accounts at the same bank is a lot easier, safer, faster, and cheaper than moving money between banks.  Furthermore, it's a lot easier to undo mistakes.

The beauty of this business model is that it has a natural viral component: not only could investment syndicates use it, but the companies they invested in could us it too.  And their employees.  And their vendors.  And there could be a whole slew of ancillary services as well.  It could be Y Combinator, but on-line and with a nationwide or even global reach.  I called it Founders Forge.  And, of course, every participant would get a secret key with which to authenticate themselves to the system and authorize transactions. Eventually, as the user base grew we would gradually become the basis of a new, more efficient and more secure financial system that would eventually and stealthily squeeze out the older, less efficient system.

Now, those of you who like to shoot holes in people's ideas, before you take pot shots at this idea please keep in mind a couple of things.  First, what you have just read is a very abbreviated version of the actual plan.  In the interests of not turning this story into War And Peace I have left out a lot of detail.  Second, I am not an idiot.  I am well aware that banks operate under a very strict regulatory regime, that they are highly risk-averse, that they avoid innovation like vampires avoid the sun.  My plan took all this into account.  I had (still have) a detailed risk-mitigation strategy.  If you really want to know, I would be more than happy to go into excruciating detail.

None of that matters to the point I want to make with this story, as you will soon see.

I took this plan to my local Wells Fargo, which was the bank where XGYC has its account.  I figured it would be an easy sell.  I would be bringing them tons of new high-quality customers.  And it was an easy sell.  The idea got a very favorable reception from the branch manager, and the pitch started working its way up the chain of command.  I stopped worrying about the bank, and started writing code.

But a few weeks later something very peculiar and unexpected happened.  By that point I had been handed off to a regional management team, and I hadn't heard from them in a while, so I sent an email asking what was going on.  They replied that Wells had changed its mind and would not do business with me.

When I asked why, they said they couldn't tell me.  All they knew was that they had received marching orders to kill the deal.

Weird.  But OK, if at first you don't succeed...

Fast forward a year and a half, and half a dozen or so banks.  Same story, again and again and again: initial enthusiasm, followed by a sudden change of heart with no explanation.  The only exception was a small regional bank where I was able to pitch directly to the CEO.  He said he loved the idea, but was couldn't do it because their charter prevented the from having non-local customers.  That was the only time I got a straight answer out of a banker.

It gets worse.

By this point I was very discouraged, but far from ready to give up.  Still, I wasn't quite sure what to do because I didn't have a good model of what was going wrong.  I had no idea what to change to increase my chances of success.  I talked to everyone I knew who had even the remotest connection with the financial world and the reaction was always the same: This is really weird.  Your pitch sounds great.  I have no idea why a bank would not want to work with you.

I kept at it.  I tried everything.  I tried credit unions.  I tried Silicon Valley Bank (which turns out to be astonishingly backwards in its approach to technology even by banking standards).  You name it, I tried it.

Finally, I caught two breaks.  The first was a bank called Square1 (no relation to Square, which wasn't founded until a few years later) which was receptive to the idea.  For the nth time I worked my way up the food chain and got to the CEO, but before I could meet with him he had a heart attack and died.  No, I am not making this up.

My second break was First Republic Bank.  I got as far as face-to-face meetings with their CTO and other senior staff.  Then one day, many months in to the process, they all stopped returning my emails.  I found out later that everyone I was dealing with had left the bank.  As far as I know, all the departures were independent and had nothing to do with me.  I tried to resurrect the deal, and got as far as a face-to-face with the new CTO.  He told me he was interested, but was ultimately unable to convince senior management.

By now I was very discouraged, but still not ready to give up.  I tried one last strategy.  Maybe the problem was me.  Maybe I was too geeky.  Maybe I didn't know the secret handshake.  So I enlisted the aid of a friend of mine, a Harvard grad, a complete non-geek, strong business credentials, blue blood, comfortable in a suit and tie.  He had been interested in being a co-founder, so I delegated the job of closing a bank deal to him, and I gave him a strong lead.  We were both extremely careful, working our way step-by-step up the chain of command, getting everyone on board, until we got to the CEO.  We pitched him, and he said yes, but with one condition: he wanted us to be venture funded.

Up to that point I was self-funded, mainly because I didn't need the money, but also because the business case was immensely stronger with a bank on board.  The whole model lived and died on the ability to quickly, cheaply, and reliably move money around, and to do that we needed a bank.  (Yes, I know about ACH.  I'll write a whole nuther post on why that wouldn't work.)  But OK, if the difference between getting my key vendor and not was raising a round, I would raise a round.  I had good VC connections, and within a week I had lined up three of them.  I called the bank back and told them about my progress, and that these VCs would like to talk to them as part of their due dilligence.  That was when this bank, too, pulled out.  No credible explanation.

That was March of 2012.  That was when I decided to fold up the tent.

But, of course, that is not the end of the story.

[UPDATE:] Responding to some comments over on Hacker News, I am not drawing this story out because I'm trying to be cagey.  I don't know why all the banks did what they did.  It's a mystery to me.  That's one of the reasons it's hard to write about.

No, it's because he was behaving like a childish jerk

Liberal news outlets are gleefully reporting an incident on Fox news this morning:
Rep. Keith Ellison, D-Minn., was kicked off of Sean Hannity’s Fox News show during a segment that started out about the sequester, but which devolved into six minutes of the two yelling at each other [emphasis added]. Ellison called Hannity everything from "the worst excuse for a journalist I’ve ever seen" to "a shill for the Republican Party."
Except that if you watch the segment you will see that it was not six minutes of the two of them yelling at each other, it was six minutes of Eillison yelling at Hannity and generally behaving like a sixth-grader, with Hannity politely trying to get a word in edgewise.  I was cringing the entire time I watched it.  I am no fan of Fox news, so it's unfortunate that Ellison's childish conduct completely overshadowed the fact that what he was saying was actually true.  Hannity is a shill for the Republican party, and he is a pathetic excuse for a journalist.  But Ellison, at least for these six minutes, was a pathetic excuse for a leader, and that is the only thing that any non-Democrat is going to remember from this interview.

Tuesday, February 26, 2013

In the interests of full disclosure...

I'm back, and I'll be posting the next installment in my series tomorrow, probably early afternoon Pacific time.  I'm announcing this because I have an ulterior motive for writing this story, and in particular for writing about it now.  I'm hoping to draw attention to the problem of regulatory capture in the financial industry because there is a bill before the California state assembly that is likely to make a bad problem even worse.  But there's a narrow window of opportunity to get this bill amended so that it makes the problem better.  By the time I'm done, I hope to convince a those of you who are citizens of California that the problem is serious, and that you can help by sending a note to the relevant people in the Assembly.  I'll provide contact information before I'm done.

In the hopes of drawing attention to the problem I've been submitting these posts to Hacker News.  The first one got quite a bit of attention, the second hardly any.  There's about an hour-long window of opportunity between the time a link is submitted to HN to the time it falls off the New page and into the cosmic void, never to be seen again.  If you have a Hacker News account I would really appreciate an upvote tomorrow afternoon.

I'm being up-front about this because I anticipate getting a lot of flack when I publish the next installment.  It's the story of a failure.  Silicon Valley loves a failure, but it hates a whiner.  They want you to fail fast, fail quietly, and move on.  And I am mostly on board with that.  Dwelling on failure is usually counterproductive.  But in this case I think there's a valuable lesson to be learned from my failure, and so I'm going to take the risk of being labelled a whiner and a sore loser in the hopes that it might spur enough people to action to do some good and get a very bad law changed for the better.

That's my agenda.  I hope that by being up-front about this it will help shield me from some of the criticism that I'm pretty sure will come if I'm successful in drawing attention to tomorrow's post.

Sunday, February 24, 2013

A simple solution to credit card fraud, part 2: a primer on public-key cryptography

This is part two (of many) of a long story.  This story is partly about credit card fraud, partly about other things, but I had to start somewhere.  In part 1 I made the claim that a technology called public key cryptography could be used to essentially eliminate credit card fraud.  This post is a primer about what public key cryptography is, how it works, and how it could be used to solve the problem.  This post was written for a non-technical audience.

Your on-line life revolves around keeping secrets: passwords, account numbers, your social security number, your mother's maiden name, etc.  The on-line (and telephone BTW) world revolves around the assumption that if you know these secrets then you must be you and not someone else.  One obvious problem with this assumption is that most of these "secrets" aren't very secret. An entire industry, identity theft, has grown up around this fact.

But it's even worse than that: the way that you normally prove to people that you know one of these secrets is by revealing it.  So anyone who can convince you that they have a legitimate need to verify your identity can coax these secrets out of you simply by tricking you into engaging in normal behavior.  That is the basis of phishing.

If only there were some way of proving that you know a certain secret without actually revealing what it is.  The world would be a better place.  You could eliminate (or at least severely curtail) phishing and identity theft.  You would have created real value, the proverbial better mousetrap.  Surely the world would beat a path to your door.  But is it even possible?  You might want to think about that and see if you can come up with any ways on your own before proceeding.

One possibility is to use a trusted intermediary.  Let's call her Tracy.  If we both trust Tracy, then I can reveal the secret to Tracy, and Tracy can tell you "Yep, Ron knows the secret" and you will believe her because you trust her (that's the definition of a trusted intermediary).  Many things in life are much easier if you have a trusted intermediary.  This is the basis for industries like notaries and escrow services.  (One of the reasons that Amazon is such a success is that it operates as a trusted intermediary between its customers and other merchants.)

But suppose we don't have access to a trusted intermediary.  Is it still possible?  Yes, it is, if we use some mathematical tricks.  The details are complicated and I'm going to skip over most of them, but the upshot is this: there are ways to take a secret number S and perform some calculations which produce a series of numbers called P, G1, G2, G3, etc. in such a way that anyone can verify that these numbers could only have been computed by someone who knows S.  So by producing P and one (or more) of these G's you can prove you know S without revealing what S is.  That's all there is to it at a conceptual level.

I have obviously skipped over a ton of details.  In particular I've skipped over how you actually do these calculations, but you can easily find that information if you really want to know.  Beware: this is a very deep rabbit hole, and it is fraught with peril.  I don't want to discourage you from pursuing this, but cryptography is one area where a little knowledge can be a very dangerous thing.  As a general rule you should never use a cryptographic algorithm for any mission-critical application unless you are an expert or have enlisted the aid of one.  But if you just want to noodle around to see for yourself how it all works under the hood, by all means, do it.  The more people understand this stuff, the better the world will be.

However, two of the details I have skipped over are very important even at a conceptual level.

First: why did I call the first result P instead of G0?  Because P is computed differently from all the G's, and it is used in the computation that verifies that the G's were computed by someone who knows S.  In the usual parlance, S is called the "secret key" and P is called the "public key".

Second: each of the G's (but not P) is associated with another number, N.  In fact, each G is computed from S and some N using the same computation.  So not only is each G proof of knowledge of S, but it is also associated with some particular number N.  This means that each G can be interpreted as a digital signature associated with N.  Moreover, this is a secure digital signature because only someone who knew S could have produced it.

We can use this to prevent credit card fraud by adopting a new protocol.  Instead of telling the merchant your (say) CVV code, you could instead use a secret key associated with your credit card to produce a digital signature for a number N that was unique to that particular transaction (an invoice number, for example).  To authorize the transaction you would take your secret key S and compute the signature Gn.  The merchant could show Gn to the bank as evidence that you authorized the transaction because Gn could only have been produced by you (since you are the only one who knows S).

Furthermore, Gn can *only* be used to authorize that *one* transaction.  It cannot be reused for any other transaction.  A fraudster might still be able to extract some money from you by getting you to authorize a fraudulent transaction (i.e. a purchase for an item that they don't send you) but they can't reuse the information to conduct any other transactions.  The black market in stolen credit card numbers would evaporate overnight.  It might be replaced by a black market in stolen secret keys, but this is still a significant improvement over the status quo because you can't easily phish a secret key.  In the normal course of events you never ever reveal your secret key to anyone, so anyone who asked for it would immediately arouse suspicion.  There are still ways that a secret key can be compromised (if someone installs malware on the computer where you store it, for example), but it is at least possible in principle to keep a secret key secret.  Keeping your credit card information secret is not possible even in principle because the current protocol requires you to hand it over for every single transaction that you conduct.

Again I must reiterate that I have skipped over a lot of details.  Making this actually work is not so easy, but a lot -- maybe even *most* -- of the things that are commonly done in the technology world are not so easy.  And yet they get done.  But this one hasn't.

Some technical details in case you're curious:

There are two main ways of performing public-key cryptography, called RSA and ECC.  RSA stands for Rivest-Shamir-Adelman, the last names of the people who invented it.  ECC stands for Elliptic Curve Cryptography, after the mathematical theory that underlies it.  RSA was invented in 1977, ECC in 1985.

RSA is based on large prime numbers.  The secret key S is not one number but two, and the public key P is the product of these two numbers.  (In RSA terminology, the two prime numbers are usually called P and Q instead of S, and the public key is called N instead of P.  There's another piece of the public key called E but you can safely ignore that at this high level.)

RSA has two main problems.  Neither of these are show-stoppers (RSA is in widespread use) but they are disadvantages.  The first is that the numbers involved are really big.  Nowadays a typical RSA key has at least 2048 bits, and the signatures are the same size.  So they can be a little unwieldy.

The second problem is that producing large random prime numbers to serve as RSA keys is not trivial.  If you are not technically savvy you probably have to get someone to do it for you, which means you have to trust them to 1) have enough technical knowledge to actually produce a strong key and 2) be trustworthy enough not to keep a copy for themselves, or to give to anyone else.  This is called the key provisioning problem.  It is very serious, and some (myself included) would say not completely solved.

ECC doesn't have either of these problems.  It uses keys that don't have to be prime numbers, and they can be a lot shorter for a given level of security.  In general, for a given level of security, an ECC key is less than a tenth the size of an RSA key.  And because they don't have to be prime numbers they are a lot easier to produce, so key provisioning is a lot easier.  But ECC is newer and less widely used, so it is not as battle-tested as RSA.

If there's enough interest I'll write up another post about the technical details of ECC, which is what Founders Forge was going to use.

Friday, February 22, 2013

An administrative note

I probably should have thought of this before I posted, but I'm at the airport on my way out of town.  My post on credit card fraud is generating a lot of feedback (thanks!) but I won't have time to respond properly until later today.  But I do appreciate the feedback, and I will respond.

Just a couple of points off the cuff:

1.  This is just the beginning of a pretty long story.  The events that led up to this unfolded over a period of nearly four years.  The issues involved are complicated, and they are complicated across multiple dimensions: technically, legally, and politically.  And I'm writing for a very broad audience that spans a very broad range of background and expertise.  So please bear with me, and cut me a little slack.

2.  The problem is not so much the failure of the banks and credit card companies to solve the fraud problem per se.  The real problem IMHO is the obstacles I encountered when I tried to start a company that would solve, not the credit card problem per se, but a related problem (that I believed, and still believe, would also solve the credit card fraud problem as a side effect).  Like I said, long story.  Bear with me.  [UPDATE: I would like to rephrase my statement of the problem: the problem is that the cost of fraud is hidden from consumers, and the industry has, through regulatory capture, erected all-but-insurmountable barriers to entry to competition.  And, by the way, when I started, Bitcoin didn't exist.  Bitcoin may well change everything.  But that is also a complicated topic in its own right.]

3.  I am not the only person to have encountered this problem, and public key crypto is not the only possible solution.  I just cited that as an example of an available solution that is not being deployed, or at least not being deployed as expeditiously as it could be.

More later.

A simple solution to credit card fraud (and why you won't see it any time soon)

This is the first in what will probably be a very long series of articles.  Ultimately, this is the beginning of the story of why I stopped writing nearly a year ago.  TL;DR: I learned some things about how the world works that I couldn't figure out how to write about without coming across like a paranoid loon, and I couldn't get them far enough out of my head to write cogently about anything else.  I'm still not sure I can tell this story without sounding like a paranoid loon, but I've decided to take that chance.

TL;DR2: There are some fairly straightforward technical solution to the problem of credit card fraud.  Some of them are new and innovative, while others are already in widespread use throughout the world, but not in the U.S.  But none of these solutions will be deployed in the U.S. any time soon, not because it's hard, but because the established players in the financial industry won't allow it.

Some of this gets technically complicated, but I'm going to try to keep it as simple as I can.  Part of the solution to the problem has to be to educate people about what is going on, so I hope this post and the ones that follow will reach a broad audience.  If you're one of my technical readers, I apologize if some of what follows sounds condescending.

So let's start with the problem, and the solution.

The fundamental problem with credit cards is that the protocol they use is fundamentally insecure.  To conduct a transaction with a credit card you have to give information to the person you're transacting with.  In particular, you have to give them your card number.  The problem is that this information is not bound to the transaction you are conducting.  It is reusable.  Once someone knows your card number they can use it to conduct any transaction they choose.  There is no security built into the system at all.  It relies entirely on trust.

This was OK back in the 1950s (or the 1930s, or 1887 depending on how you count) when credit cards were first invented.  Back then you had to be physically present to conduct a transaction.  The risk of getting caught if you decided to try to commit credit card fraud was high enough that it was (mostly) an effective deterrent.

In the 1960s merchants began to accept credit cards for orders placed over the telephone.  This decreased the risk of getting caught, and fraud began to be a major problem.  Those of us who grew up in the 1960s and 70s will remember merchants leafing through paper directories of compromised credit card numbers issued on a regular basis by the card companies.

With the advent of the internet and e-comerce in the 1990s, the risk of getting caught committing credit card fraud dropped essentially to zero, especially if you were located in a different country.  The result was the beginning of the epidemic of card fraud and identity theft we see today.

There are technological solutions to this problem.  The most effective (IMHO) is a technology that was first invented in the 1970s and has since become widely used called public-key cryptography.  I don't want to get too deeply into the technological weeds at this point in the story, so for now just take my word for it: using this technology, it is possible to design protocols that allow the information exchanged to conduct a financial transaction to be strongly bound to that one transaction so it can't be reused.  Deploying this technology would essentially solve the problem of credit card fraud, and save the world's economy billions of dollars a year.

So why hasn't it been done?

It's not because no one has tried.  I took a serious whack at it starting in December 2008.  I finally folded up the tent on that effort in March of last year (shortly after I stopped writing, and the two events are not unrelated).  The story of that effort is long and complicated, but the upshot is this: the financial industry has erected barriers to entry that are much more effective than I ever dreamed possible in an ostensibly democratic and capitalistic society.  It is not just me who has failed to deploy public-key encryption technology in the United States, no one has been able to do it.  I don't know how many serious attempts there have been besides my own, but I do know that public-key technology has been successfully deployed in other parts of the world, notably Asia and Europe.  Furthermore, this is no secret.  I wouldn't say that everyone knows it (one of the shocking things I learned is that there are profoundly disturbing levels of ignorance about how the financial system works even among people who work in the industry) but it is widely known.

Why has the credit card industry not deployed this technology?  Surely all this fraud is costing them money, so they have a strong incentive to fix it?  Well, no.  Fraud isn't costing them money, it is costing you money.  All of the costs of processing credit cards, including the cost of fraud, is passed on by the card companies and the banks to the merchants, who in turn pass the cost on to you, the consumer.  Worse, until very recently, merchants were contractually forbidden from letting you know that these costs were being passed on to you.  In a free market, the way this would sort itself out is that merchants would charge extra for paying with a credit card to reflect the extra costs associated with them.  But until last year, this was forbidden, not by law, but by the card companies' terms of service.

Even just this little corner of the problem is far from being resolved.  It's complicated.  The whole situation is horribly, horribly complicated, which is one of the things that makes it so hard to write about, and why I wedged on it for nearly a year.  (Maybe I'm still wedged.  We'll see.)

I'm going to leave it at that for now.  This story is going to be a long haul.  But I'll give you a sneak preview of things to come by pointing out two facts: 1) no one has gone to prison as a result of the sub-prime disaster.  No one has even been brought to trial.  And 2) Hong Kong Savings Bank was recently caught red-handed laundering vast amounts of money for drug cartels over a ten-year period.  The punishment they received was a fine amounting to about a month's worth of profits.

Neither of those things surprises me any more.

Thursday, February 21, 2013

A brief program note and market survey

I'm getting to the end of the Antarctica story, and so the Ramblings will soon be turning to more serious matters.  In particular, I'm going to start tackling the long, long story of why I stopped writing for nearly a year.  One of the reasons that it has taken me so long to get to this point is that telling this story entails some risk.  There are certain advantages to staying off the radar.  But I can't seem to resist the urge to tilt at windmills.

As a sneak preview of what's coming, here's a story that appeared today on Bloomberg:

On television, in interviews and in meetings with investors, executives of the biggest U.S. banks -- notably JPMorgan Chase & Co. Chief Executive Jamie Dimon -- make the case that size is a competitive advantage. It helps them lower costs and vie for customers on an international scale. Limiting it, they warn, would impair profitability and weaken the country’s position in global finance. 
So what if we told you that, by our calculations, the largest U.S. banks aren’t really profitable at all? What if the billions of dollars they allegedly earn for their shareholders were almost entirely a gift from U.S. taxpayers? 
Granted, it’s a hard concept to swallow. It’s also crucial to understanding why the big banks present such a threat to the global economy.
That was the program note.  Now the market survey part: suppose I told you that the situation in the banking industry is even worse, perhaps even a good deal worse, than what the Bloomberg story indicates, would you be inclined to believe me, or dismiss me as being paranoid?

The reason I want to know is that this story needs to be told differently depending on whether I writing for a sympathetic or a skeptical audience, and because so many of you seem to be lurking I really don't know.  So please take a moment to do the following: down at the bottom of this post you will find four checkboxes labelled "Reactions:"  Please click on one of them depending on how you reacted to the question I posed above.  And if you don't have a strong feeling about it one way or the other, please click on "Read it" so that I can get some idea of how big my audience is.  (And please feel free to use those buttons on other posts as well.  It really helps me when I try to come up with things to write about.)

Thanks in advance.

[UPDATE] If you're reading this on a newsfeed, the link to the Blogger page with the reaction buttons is here.

Sunday, February 17, 2013

[Travelogue] Antarctica, part 8

We spent the next few days slowly cruising south along the west coast of the antarctic peninsula, though never making landfall on the continent itself, only on the surrounding islands.  One of these, Deception Island, is an active volcano.  The caldera has a narrow opening just big enough to squeeze a ship through called Neptune's Bellows.  As we approached we hit a snow squall, and I grabbed this photo of one of the passengers out in it in shorts and slippers.

There are thermal springs that bubble up through the sand and send hot steam into the air, giving the place an otherworldly feel.

Some people actually went swimming here, in a masochistic tourist ritual called the antarctic plunge.  Unfortunately, I decided to give it a miss, so I don't have any good pictures of the crazy people in the water.

I particularly like this photo because it looks like I've run it through a sepia filter or something, but I haven't.  This is what the place really looked like:

The next few days were more of the same: lots of penguins, lots of ice.

To give you some idea of the scale, look at the little black dots in the lower left hand corner of the iceberg in the photo above.  Those are penguins.  Here's a close up:

Saturday, February 16, 2013

How big was the Chelyabinsk meteor?

There is a huge discrepancy in reports of the size of the Chelyabinsk meteor.  Some apparently reliable sources put it at 10-30 tons, while others have it at 7,000-10,000 tons.  This is an enormous discrepancy.  Can we figure out which one is correct?

All accounts agree that the speed of the meteor was 30,000-40,000 miles per hour, which is pretty much the going rate for meteors.  That works out to about 15,000 meters per second.  The kinetic energy of a moving object is 1/2 times the mass times the velocity squared.  For this rough calculation we can ignore the 1/2 (we're looking at a two-order-of-magnitude discrepancy here).  So a ten ton (10,000 kg) meteor moving at 15,000 m/s has an energy of about 10^12 Joules.  That's less than one kiloton of TNT, not nearly enough to cause the kind of widespread damage that was reported.

So the 7000-10,000 ton figure is almost certainly the correct one.

It's a doggone mystery

A study has confirmed what dog owners around the world already know: dogs can recognize other dogs:
Dogs pick out faces of other dogs, irrespective of breeds, among human and other domestic and wild animal faces and can group them into a category of their own. They do that using visual cues alone, according to new research by Dr. Dominique Autier-Dérian from the LEEC and National Veterinary School in Lyon in France and colleagues. Their work, the first to test dogs' ability to discriminate between species and form a "dog" category in spite of the huge variability within the dog species, is published online in Springer's journal Animal Cognition.
If you think about it, a modern dog's ability to visually recognize other dogs is a deep mystery.  Most extant dog breeds have only existed for a few hundred years, and many bear very little resemblance to anything in a dog's ancestral environment.  That's not nearly enough time for an innate ability to recognize dogs to have evolved.  So there are only two possibilities:

1. The ability to recognize other breeds was somehow wired into the brains of dogs before those breeds actually existed, or

2.  Dogs somehow learn how to recognize other dogs, including breeds that they may never before have encountered

It would be interesting to design a study to try to suss this out.  Either way, it's pretty cool that dogs (and people too, for that matter) can recognize these:

When the training set in the ancestral environment looked like this:

Friday, February 15, 2013

It's a question of when, not if

Unless you are living in a cave, you will have heard by now of the huge meteor exploding over Russia.  Except that it wasn't particularly huge, and it didn't explode.  The Chelyabinsk meteor weighed about ten tons, [UPDATE: Nature says it was 7000 tons.  That's a big discrepancy, but maybe they meant 7000 kilograms.  I'm trying to find out which source was wrong. and the "explosion" was just the shock wave that it produced as it plowed through the atmosphere at supersonic speeds.  If the meteor was made of iron (which it almost certainly was) it would have been about a meter or two in diameter.  [UPDATE2: Nature was right, it was 7-10 thousand tons.  That would make it about 10 meters in diameter.]

Those are not the scary rocks.

The scary rocks are the ones that are 100 meters or so in diameter, about the size of a football field.  Those are scary because they are too small to be seen with ground-based telescopes, but when -- not if -- one of those hits it will without a doubt ruin your day no matter where on earth you happen to be.  Watch the videos of the Chelyabinsk event and then imagine a rock that weighs a million times more.  Such a rock hits the earth on average once every 10,000 years.  A Chelyabinsk-sized rock hits every 100 years or so.  The last one was in 1908, so this one was right about on schedule.  (Tunguska was almost certainly a comet, not an asteroid, but the energy released was comparable -- Tunguska was probably a little higher.  [UPDATE] I got this wrong.  Tunguska was a LOT bigger, but because it disintegrated in the atmosphere over an unpopulated area it didn't cause much damage other than a lot of toppled trees.).

The asteroid that wiped out the dinosaurs was about ten kilometers in diameter.  Those hit every hundred million years or so.  They're pretty rare, and they're big enough to see, so we know that we aren't in any imminent danger.  (Still, it's a little sobering to think that about forty of those have hit the earth since it was formed!)

The little rocks, like the one that hit Chelyabinsk, mostly burn up in the atmosphere or cause minor damage.

But, like I said, the 100-meter-sized rocks are the scary ones.  There are a lot of them, and they're hard to see so we don't know where the vast majority of them are.  An impact by a 100-meter asteroid would not be an extinction-level event, but it could be a civilization-ender.  It would without a doubt be the worst natural disaster in recorded history by a huge margin.  If it hit in water (the most likely scenario) it would cause 1000-meter-high tsunamis. For comparison, the tsunami that destroyed the Fukushima nuclear plant was 10 meters high.

There is about a one percent chance that this will happen in your grandchildren's lifetime.

Take a moment to think about that.

Happily, there is actually something we can do about it.  We have the technology to find and even divert 100-meter-sized asteroids.  And it isn't even very expensive in the grand and glorious scheme of things, in the neighborhood of $500 million or so.  That's less than half the cost of a single B-2 bomber.

I don't proselytize much here on the Ramblings, but in this case I'll make an exception: if you care about the future of civilization, I urge you to go to the web site of the B612 Foundation (the name comes from the home of the Little Prince) and, at a minimum, sign up for their mailing list.  B612 was founded by a pair of NASA astronauts, Ed Lu and Rusty Schweickart.  They know what they are doing, and they have a plan that will work -- if it can get funded.  The more people they have on their mailing list, the more likely they are to be able to attract the attention of a person or institution capable of providing that funding.

So do your bit to save the planet: sign up for B612's mailing list.  Do it now.  And if you're really feeling motivated, make a donation.  Every little bit helps.

[Travelogue] Antarctica part 7

On our second day at sea heading for the Antarctic peninsula I had a follow up meeting with Richard Dawkins to talk about the proposal I had written up for him a few days earlier.  TL;DR version: he was not interested in participating or even endorsing the idea, but he would be willing to provide some introductions, most notably to The Clergy Project, where he thought I might find a more sympathetic audience.

Since neither of us had anyplace to go I decided to try an audacious experiment.  About three years ago, while on another cruise, I wrote an imaginary dialog between myself and a prominent YouTube atheist who goes by the handle QualiaSoup.  It advances an argument for the proposition that the idea of God has many (but of course not all) of the same properties that God would have if he existed.  Thus one can plausibly claim that God exists if one defines God as an idea, an axiom that many theists would subscribe to.  It's a bit of a stretch, but I think the argument actually holds up pretty well, even after all this time.

I decided to try this argument out on Richard to see how far I got.  (NB: I told him up front what I wanted to do and asked him if he was OK with it.)  TL;DR: I got a lot further than I was expecting to.  I got a little hung up on the circularity of redefining God as the-idea-of-God and had to on-the-fly coin the terms God1 (a supernatural being, which does not exist) and God2 (the idea of God1, which does exist, and which can have real effects, some of them beneficial).  But in the end I ran out of steam and could not convince him that there was a point, that there was a useful distinction to be drawn between fiction and falsehood.  (I think his exact words were, "But what's the point if it isn't true?")  So in the end I took my best shot at reforming Richard Dawkins and I failed.  But I'm grateful that fate afforded me the opportunity.  And the some of the leads he gave me are still active and may result in something some day.  Stay tuned.

In the meantime, the ship had to divert its course to the north because there was much more sea ice coming up from the Weddell Sea than had been expected (almost certainly a consequence of global warming).  Our captain (the coolest captain ever) had an open bridge policy, so I spent some time there watching the crew dodge icebergs. There's a whole terminology associated with ice.  Little pieces of ice are called growlers (I guess because of the sound they make as they scrape against the hull).  Slightly larger chunks of ice are called bergy bits (no, I am not making this up) but I was never entirely clear on where the dividing line was.  There are also lots of different kinds of icebergs, but I won't bore you with the details.

As a result of the unexpected ice our scheduled stop at Elephant Island had to be cancelled and instead we ended up at another one of the South Shetland Islands (I can't remember which one now, but I think it was Nelson Island).  We didn't land there, but we did get a zodiac tour.  I'll let the pictures speak for themselves.

(BTW, in case you haven't already realized it, you can click on these images and get larger versions.)

Monday, February 11, 2013

Funny you should mention that...

Tony Mach, in a recent comment, wrote:
I find it nice to read your perspective about all things related to economy, and how it is one big capitalistic cluster-fark.
First, thanks for the feedback, Tony.  Because this blog doesn't really have a theme its sometimes hard to decide what to write about.

But the economy is a subject that is near and dear to my heart, and also related in a very intimate way to the very, very long story of why I stopped writing nearly a year ago.  The TL;DR version is that at the end of a multi-year process I came to realize some things about how the world actually works under the hood that left me in a full-blown existential crisis.

I'm still struggling with how (or even whether) to tell the whole story.  But in the meantime, here's a data point.

[Travelogue] Antarctica, part 6

One of the  more annoying aspects of the cruise was the schedule.  There were 200 passengers on the ship, but because of environmental regulations only 100 could go ashore at once, so we had to go in shifts, and they would try to get in two landings a day.  So the early shift was pretty frickin' early, at least by my night-owl standards.

Trick is, they would broadcast a wakeup call over the loudspeaker into our cabins in the mornings, but they had no way of selecting which cabins got the announcement.  Everyone was awakened bright and early whether or not we were on the first shift.  So after we left South Georgia heading out across the Southern Ocean I was really looking forward to sleeping in.  We had two days at sea before reaching Elephant Island.

So I was pretty frickin' annoyed when at 6AM on the first day the captain came on to loudspeaker and said, "Ladies and gentlemen I apologize for waking you up but we are approaching a very special iceberg.  You really should get up and have a look at it."

Are you fucking kidding me?  We're heading to Antarctica.  Icebergs are going to be a dime a dozen.  This had better be the best damned iceberg the world has ever seen.  Grumble grumble.

I dragged myself out of bed and over to the window.

Holy shit.

It was a mile wide, and as you can see, it had spectacular arches around the entire perimeter.

I said to Nancy, "You really should have a look at this.  It's worth getting up for."

Nancy said, "Mmmrmrmmmrrmm...."

But the captain didn't leave her a choice.  A few minutes later he came on the PA again and said, "You need to get up to see this iceberg.  This is the most spectacular iceberg I have ever seen.  You can sleep when we get back to Ushuaia.  I can hardly contain myself!"

Yes, he really said that.  I wanted to nominate him for Coolest Captain Ever.

What is it about the CSS thing?

Good grief!  Since I started blogging again two months ago I've averaged about 1 comment per post.  (That's pretty disheartening by the way.  Sometimes I stare at all the "No comments" at the bottom of my posts and wonder if anyone is reading this.)  But this post that I wrote four years ago is still getting comments!  253 of them and counting!  I got two new comments on that post just today.  (I decided not to publish one because it was too rude.)

Maybe I should just stick to writing about CSS and jerking people's chains. :-(

BTW, I have not been keeping up with the latest developments in CSS, but I just did a little Googling and found this post from 2011, two years after I wrote my "CSS should not be used for layout" post.  It makes me feel completely vindicated.

Sunday, February 10, 2013

This is what leadership looks like

For those of you who may have forgotten since we see so little of it nowadays:

There's also a transcript of the English translation for those of you who don't want to take the time to watch the video, but I think it's worthwhile even if you don't understand Hebrew. This is an extremely rare example of politician telling an unsympathetic audience something they don't want to hear, and doing it brilliantly. Well worth the time.

Friday, February 01, 2013

[Travelogue] Antarctica, part 5, or My Date with Richard

On Christmas day the weather turned 'round on us again and it was so windy we couldn't make any landings at all. We ended up doing a scenic tour of Drygalski fjord, and even that turned out to be a little dicey because of how hard the wind was blowing.  We learned later that the boat doing the same tour a few days behind us wasn't able to make any landings on South Georgia at all.  Such is the way of the Antarctic.

So we headed to sea, towards the northern tip of the Antarctic peninsula.  We wouldn't see land again for three days, which gave me plenty of opportunities to chat with my fellow passenger, Richard Dawkins.

Regular readers of my blog will know that I am at once a big fan of his (I think "The Selfish Gene" is one of the greatest books ever written) and a harsh critic, not just of Richard, but of the strident rhetoric employed by all of the so-called "new atheists."  I believe that religion thrives because it fulfills a legitimate human need, and that secular movements would prosper more if they recognized that fact rather than try to sweep all religion under the rug as worthless nonsense at best, and the source of all evil at worst.  Yes, religion is fiction, but it is not merely fiction.  We are story-telling animals, and fiction can be powerful JuJu, a fact that we ignore at our peril.

I was salivating at the prospect of having the opportunity to make that argument to The Man himself.

The four of us (me, Richard, Nancy, and Richard's wife Lalla) had dinner together that night, and to make a long story short, Richard was much more receptive to my argument than I ever imagined he would be.  He basically just said yes to everything I said, and a conversation that I expected to last an hour or two was over in five minutes.  Suddenly I was at a loss for what to say next, but it's not every day that one gets to have a private conversation with someone of Richard's stature, so I decided to press my luck.  Shooting from the hip I said, "Why don't you start a church?"  He responded, "That sounds like an interesting idea, tell me more."

So I did.  Of course, I was making it up on the spot, but I must have done a reasonable job because at the end of the pitch he said, "Sounds good, why don't you write up a proposal?"

I was flabbergasted.  In my wildest dreams I have never imagined that he would be so receptive to the idea, and at that point I was truly speechless.

So the conversation turned to ties.  Yes, I know, it sounds deadly dull, but Lalla is an artist and one of the things she does is make hand-painted ties.  She paints animals, and Richard was wearing one of her ties (penguins, of course).  Beautiful work.  Lalla, if you're reading this, I still want one :-)

One of the stories Richard was fond of telling was wearing a warthog tie when he was invited to lunch with Queen Elizabeth.  The queen, evidently not a big fan of warthogs, asked him, "Why do you have such an ugly animal on your tie?"  He replied, "If it is an ugly animal how much greater the artistry to fashion it into such a beautiful tie."  What a great line.

I stayed up late writing up a draft proposal for what I ended up dubbing the Church of Natural Cosmology.

(To be continued...)