Both.  ID and proof of address.

I don't think I see an answer to this question--

In the world of LOG-O-RHYTHMS, baby!  Yeah, that's right!
All kidding aside, for measurements covering many decades, logarithms are the only sensible approach.

Also, regarding verification, Bitfinex requests a utility bill or phone bill.
I have no utility bills, so I must use a phone bill.  Does it matter whether the bill comes from a legacy landline provider, or a cellular provider?
I actually have two phone bills, one is for a flip phone (voice) and the other is a tablet (data).  But I don't use a traditional landline telephone.

You are so harshing my mellow!
Time to get a VPN?  Or use a live USB with tails, which goes through tor.  But the tor exit node might just be run by the NSA.

Touche'
Looks like both url's go to www.random.org, the difference is whether you use SSL, am I right about that? 

Depending on what you want to use it for, you might want to make sure you get the one that uses SSL.

I had to go look at the bitaddress.org website to see what you're talking about.
I didn't know bitaddress.org had a place where you could input a raw number as a key, and have it do the WIF conversion for you.
Whether you use random.org, dice or cards, it's the same thing.  You generate a 256 bit number (randomly).  That's your key.
Actually, 6^99 = 2^255.9112876 so it's not ezackly 256 bits.

Yes.
By generating a random 256 bit number you are skipping the first step of making a passphrase, and the second step of hashing the passphrase to get a 256 bit number.
I just generated a 256 bit number by going to random.org and telling it to generate a random number in the range of 0 to 65535.  That's 65536 possibilities, which is 16^4 or four hex characters.  So if you do this 16 times, you can get 64 hex characters, which is a private key.  Random.org generates decimal numbers, so you convert 16 numbers from random.org into hex and you get sixteen four-digit hex numbers that you can concatenate for the private key.  Then you can encode it into base58check.  Brainwallet.org will do that for you, but for the paranoid, it can be done at the linux command line.

It occurs to me that if one wants to go to the trouble of generating truly random strings, then you don't have to go through bitaddress.org to make your key.
Bitaddress.org uses a hash to generate a 256 bit number from your passphrase.  But if you are going to generate entropy legitimately, you can just cut straight to the chase.  Skip the hash.  Generate a 256 bit random number and use the number itself as the payload.  This 256 bits is your real private key; you just have to encode it in base58check (Wallet Import Format) to make a key you can use.  There's a fairly simple process to do that, involving a couple of hashes to generate the checksum (this is built into Bitaddress.org, but you are skipping the passphrase hashing step so you have to do the encoding yourself).  
Any linux distro ought to be able to do the hashes.

In principle, no difference.  But when the average person takes a deck of card and gives it a few shuffles, the deck may have some residual order.  I don't think a fair die exhibits the same potential weakness.  Physical intuition tells me that as long as the die bounces a few times before settling down, the result is essentially unpredictable.  So in this respect, cards may be the weaker choice.

Having said that, I still think that cards are quite adequate for generating entropy, as long as you know what you're doing.  Start by reading the wikipedia page on card shuffling:
http://en.wikipedia.org/wiki/Shuffling
I find this sentence particularly interesting:
"seven shuffles of a new deck leaves an 81% probability of winning New Age Solitaire where the probability is 50% with a uniform random deck"

Considering the sophistication of hackers and the computing power at their command, having any residual pattern to the arrangement of the cards poses a risk.  If cards become a commonly used technique for generating passphrases, the hackers will know about it and tailor their cracking techniques to any pattern known to result from weak shuffling.  Therefore

Good shuffling is critically important.  

I don't limit my shuffling to riffles.  I also use an overhand shuffle where I hold the deck in my right hand and slide a few cards at a time off the top of the deck into my left hand.  This is a very easy shuffle.  I guess a dozen overhand shuffles alternating with a dozen riffles would do it, but considering how easy and quick it is to shuffle a deck of cards, it wouldn't hurt you to do more.  

Each passphrase only uses a couple of dozen cards, so you can generate two passphrases from a shuffled deck.

I would make a brain wallet using cards like this:
Take a pack of cards and a sharpie.  Go through the deck and on each card write one symbol from the base58 list, which you can find here:
https://en.bitcoin.it/wiki/Base58Check_encoding
(That list leaves out zero and capital O, and it leaves out capital I and small l (ell), helping to avoid confusion.)
You won't use up all the symbols in the list, but that's ok.
Riffle shuffle the deck a dozen times or more, you want to completely randomize it.
Take a stack of about 20 to 24 cards from the shuffled deck, depending on how much entropy you think you need (see previous post).  Go get a piece of paper and pen.  Then turn over the cards one by one and write down each letter and number in sequence.  This is your passphrase, which you need to type into your offline bitaddress utility to generate the WIF private key and bitcoin address for your new wallet.  Best practice is to use a live cd or usb with the bitaddress html stored on it, and your machine's wifi turned off.
To save your passphrase, you can keep the deck and make sure the cards don't get mixed up, but it's easier to keep the piece of paper you wrote the passphrase on and forget about the cards.  I think it's safer too, because with a stack of cards there's always the risk of dropping them and getting them mixed up.

Re: live usb.  If you make a live usb that's non-persistent, you can still put the bitaddress html on it.  Just plug the usb into a machine that's already booted up and save a file with the html code in the root directory.  Then when you boot from the live usb, there should be a directory with the html code in it.  On my ubuntu live usb, it appears in a directory called CD, or CDRom, something like that.

52 different cards, thoroughly shuffled, and I mean thoroughly, would get you 225 bits of entropy.  More than you really need for a secure key.
Let's say you chose twenty cards randomly from a full deck of 52, and throw away the leftover cards.  Now you have twenty objects chosen randomly from a set of 52.
Adopting the strategy in your post, we preserve the order of the cards -- so we can treat this as an ordered set.  There are 52 possibilities for the first card, 51 possibilities for the second card, and so on.  So the number of possible twenty-card ordered decks is 52 factorial divided by 32 factorial.  (Assuming complete randomness in the selection.)  If you have a thoroughly shuffled 52 card deck, you can just take the top twenty cards, in order, and go with that.
Type "52!/32!" (without the quotes) in the Google search box and it tells you the answer is 3.065 x 10^32.  This is the entropy, but you want it expressed as a power of two, so
2^x=3.065x10^32  solving x =  107.9 bits of entropy
That's generally accepted as enough passphrase strength for today's computers and some decades into the future.  If you want a stronger password use more cards and recalculate.  If you add just one more card, it will garner you exactly 5 bits more entropy, because it is chosen from exactly 32 leftover cards, and 2^5=32.  
Thus 21 cards gives 112.9 bits of entropy.  Each card you add after that will add entropy, but not as much.

Okay, that covers the math, the next question is how do you convert a deck of cards into a passphrase.  You could convert the ordered cards into a base58 string by assigning a letter or number to each card in any way that seems logical to you, using 52 symbols out of the base 58 set.  You convert that string into a key by treating it as your passphrase.

Of course you have to record the numbering scheme you used and store that somewhere, if you ever want to regenerate the passphrase.  So you have to keep the deck and a list of the letters and numbers you assigned to the cards.  Also, you have to know which end of the deck you're counting from.  It would be less work just to write down the passphrase.

So what advantage would you get from using a deck of cards?  Keep the cards in one location and the symbols list in another location, I suppose...
Mostly, the utility comes from the ability to get a random string by shuffling cards.  The actual storing of the passphrase is another issue that might be solved more effectively by some other method than holding a deck of cards.

Does it copy the key to clipboard unencrypted or encrypted? 

I have the same problem lysdexic had.  I started bank verification a couple of weeks ago and never got the trial deposits.  Tried online chat and gave up, no response after four minutes.  Phone call diverted to voice mail after a while.
Can't see any way to restart the bank verification process.
DeathAndTaxes:  I sent you a PM with my bitsimple username.

Okay, you want to use the wisdom of the crowd to get a bitcoin price prognosis.  Excellent idea!  You may get a pretty darn accurate prediction, if you get enough contestants.  Unfortunately, I am  not likely to be one of them, because

* It would take me a lot of time to understand how the heck this contest works.
* I'm kind of too cheap to shell out for it.

You might get quite a few more contestants if you dumb it down.  Put up a page with a histogram you can easily manipulate through a GUI to adjust the location of the peak (or peaks), the standard deviation, and how fat the tails are.  Maybe you can do that without sacrificing the underlying sophistication of the math behind your contest.  Lots more work, of course, but it might be worth it, if it garners you hundreds of contestants instead of a few mathletes.

Jan
Thanks for the clarification.

Re:  installing  mycelium on a spare mobile device

On the primary device I enabled aggregate view and backed up the wallet.
(I presume backing up multiple keys (the primary wallet) requires aggregate view; I don't see how choosing a single key and backing it up would back up any other keys.)
Went to the auxiliary device, enabled aggregate view, and added the backup key.
It only imported a single key, not the five keys I had on the primary wallet.  Or rather, it returned a message that the key was already present.
I tried disabling aggregate view in the auxiliary device's wallet and got the same result.
Next I'm going to try deleting that key in the auxiliary device's wallet, maybe then the import will work.

Edit:
I decided to back up the keys one at a time.  I backed up one key, and it went ok.
Then I made a backup of the second key, tried to import it on the auxiliary device, and it gave me the message that the key was already present.  But it was not.  Is it actually impossible for me to import my mycelium wallet on a second device, even key by key?

I have backups of these keys elsewhere that I can use to build the auxiliary wallet, but I wish I could just import the whole wallet onto the auxiliary device in a single step from a backup of the wallet on the primary device.

The app was showing half a dozen menu choices, but none was "delete."  
Turns out I have to back up the key before mycelium will let me delete it.  I didn't back up that key, of course, because I never used it and was not going to..
But I can understand why you put that mechanism in place.  It prevents loss of keys that aren't backed up.
So I'll spend the time backing up the key so I can delete it.

Yes, I did, and now there's a leftover key that I'm not going to use on the auxiliary device; can you tell me how to delete it?

Don't worry, I'm not gonna burn my fingers.
Hey, while I was investigating this, I found something pretty cool:
https://github.com/gbraad/html5-google-authenticator
check out the "deployed test version"
http://gauth.apps.gbraad.nl/
it works!
You can save the code and run it offline.
A thread here
http://superuser.com/questions/462478/is-there-a-google-authenticator-desktop-client
mentions some other GA utilities