I actually made this almost entirely from frozen ingredients and it was just fine. Fresh might be better.

Finely chopped leek
Smoked bacon, sliced (I used some lardons I had in the freezer)
Cubed potatoes
Chicken stock (maybe fish stock would be better, I didn’t have any) or water
Milk (about half as much as stock)
Pepper
Mace
Cod
King prawns
Sweetcorn
Cream

Fry the leeks and bacon in a little butter/olive oil (I used both) until pretty soft – I didn’t crisp the bacon for a change. I think it is better for chowder not to. Add cubed potatoes and fry for a bit longer, then add chicken stock (or water or fish stock) and bring to the boil. Simmer until the potatoes have softened, then zap half the mixture with a blender (I just did this in situ). Season (I didn’t need salt, there was enough in the bacon). Add milk, fish, prawns and bring back up to a simmer, cook for a few minutes, making sure the fish falls apart. Add cooked sweetcorn and bring back up to temperature. Finally, add some cream.

Quantities should be chosen so that the final result is good and thick.

Serve with warm, crusty bread and butter. Works as a whole meal.

Share This

Eric Schmidt allegedly said

“The only way to manage this is true transparency and no anonymity. In a world of asynchronous threats, it is too dangerous for there not to be some way to identify you. We need a [verified] name service for people. Governments will demand it.”

I don’t care whether he actually said it, but it neatly illustrates my point. The trouble with allowing policy makers, CEOs and journalists define technical solutions is that their ability to do so is constrained by their limited understanding of the available technologies. At Google (who I emphatically do not represent in this post), we have this idea that engineers should design the systems they work on. I approve of this idea, so, speaking as a practising engineer in the field of blame (also known as security), I contend that what Eric really should have allegedly said was that the only way to manage this is true ability to blame. When something goes wrong, we should be able to track down the culprit. Governments will demand it.

Imagine if, the next time you got on a plane, instead of showing your passport, you instead handed over an envelope with a fancy seal on it, containing your ID, with windows showing just enough to get you on the plane (e.g. your ticket number and photo). The envelope could be opened on the order of a competent court, should it turn out you did something naughty whilst travelling, but otherwise you would remain unidentified. Would this not achieve the true aim that Eric allegedly thinks should be solved by universal identification? And is it not, when spread to everything, a better answer?

Of course, in the physical world this is actually quite hard to pull off, tamper-proof and -evident seals being what they are (i.e. crap), but in the electronic world we can actually do it. We have the crypto.

Just sayin’.

Share This

Anyway, at USENIX Security this week, we won Best Student Paper. A PC member described the paper to me as “excellent” and “very important”. Robert has also blogged about it rather more eloquently than I can manage at this time in the morning.

You can read the paper, too, if you want.

Even more exciting, FreeBSD 9 will include the Capsicum capability framework, allowing the peaceful coexistence of capability and POSIX programs. Although this has been attempted before, as far as I am aware all previous versions have put a POSIX emulation layer on top of a capability system, rather than grafting capabilities onto POSIX. Since Capsicum is highly efficient and FreeBSD is a perfectly sound and portable system (and my server OS of choice), this opens up the possibility of a gradual migration to capabilities, something that has been problem up to now.

Robert and I (and a host of others) are continuing our research into practical capability systems, Robert at Cambridge and me at Google. Work is also in progress to port Capsicum to Linux.

Share This

So … what can I use on MacOS that’s less crap than Adium but still supports OTR?

Share This

Smoked bacon
Cabbage (we used sweetheart, but I don’t think it is critical, savoy would probably be even nicer)
Frozen peas
Double cream

Slice the bacon thinly, fry in a little oil until crispy (at least, that’s what I’d do, my sous-chef decided to stop sooner than that and it was fine), chop cabbage into strips, add to the bacon+fat and braise (I found I didn’t need a lid at all, but you may – and even may need to add a little water, depending on the cabbage). When the cabbage is nearly done, add the frozen peas. As soon as they defrost, a generous gloop of double cream. Add salt at some point if the bacon isn’t too salty and pepper in any case.

We ate this with roast pork belly and roast potatoes. Yummy.

Share This

I’ve updated the protocol slightly to correct a subtle bug in the secret splitting specification. You can find the latest versions and diffs here.

I’ve also finally got around to tidying the code up some (though there’s still plenty more to do), you can find an appspot server, a command line client and various libraries, all in Python, at nigori.googlecode.com. As always, patches are welcome!

The code does not fully reflect the draft protocol yet – in particular, it still uses a Schnorr signature where the draft calls for DSA.

If you want to play with the command-line client, I already have a server running on appspot. Here’s how … from the client directory, run

$ ./client.sh nigori-server.appspot.com 80 register name password
200 OK

$ ./client.sh nigori-server.appspot.com 80 authenticate name password
200 OK

Replaying: this should fail
401 Unauthorized

$ ./client.sh nigori-server.appspot.com 80 add user password name secret
/usr/local/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
  RandomPool_DeprecationWarning)
200 OK
Status: 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Content-Length: 0

$ ./client.sh nigori-server.appspot.com 80 get user password name
0 at 1277559350.600000: secret

Not the most elegant interface in the world. Note that the server is experimental, I may break it, delete all the data, etc. Of course, you can run your own.

Note also that the whole protocol is experimental at this point, I wouldn’t rely on it to store your vital passwords just yet!

Share This

Share This

At this rate it will be two years before the fix is widely adopted!

The second is about version intolerance – scarily, nearly 90% of patched servers will not work when a future version of TLS bumps the major version number to 4 (it is currently 3). This is pretty astonishingly crap, and is likely to cause us problems in the future, so I’m glad the Opera guys are working hard to track down the culprits.

By the way, at least according to Opera, OpenSSL does not have this problem.

Share This

I’ve been following the debate around XAuth with interest. Whilst the debate about whether centralisation is an acceptable stepping stone to an in-browser service is interesting, I am concerned about the functionality of either solution.

As it stands, XAuth reveals to each relying party all of my identity providers, so that it can then present UI to allow me to choose one of them to authenticate to the RP. Why? What business of the RP is it where I have accounts? All that should be revealed is the IdP I choose to reveal (if any). This seems easy enough to accomplish, even in the existing centralised version: all that has to happen is for the script that xauth.org serves is to include the UI for IdP choice.

This is not just privacy religion (or theatre): as the EFF vividly illustrated with their Panopticlick experiment, it is surprisingly easy to uniquely identify people from signals you would have thought were not at all identifying, such as browser version and configuration information. Indeed, a mere 33 IdPs would provide enough information (if evenly distributed) to uniquely identify every person in the world. Meebo had no difficulty at all coming up with 15 of them for page one of many in their introductory blog post…

Share This

Comments welcome, of course, and I should note that some details are likely to change as we get experience with implementation.

Share This