Links

Ben Laurie blathering

5 May 2008

Petition Against Unfair Motorcycle Tax

Filed under: Motorbikes — Ben @ 12:37

Not much I can add to the petition’s own words! Sign up here.

Changes to the law mean cars emitting less than 100g of CO2 per kilometre travelled would be exempt from paying Vehicle Excise Duty (road tax), while motorcycles are still required to pay.

This was outlined by your Chancellor Alistair Darling in his first budget last week, under the auspices of rewarding motorists for driving ‘green’ vehicles.

Despite Darling’s aim, the rate of road tax paid by motorcyclists is set to double in 2009, with the annual charge for a typical 125cc commuter bike set to grow from £15 per year at present, to £33 in 2009.

This makes a nonsense of the revised rates of vehicle excise duty, as motorcycles tend to emit less CO2 and use less fuel than cars, with the average CO2 output from motorcycles at 110g/km.

So why do those who ride greener two wheeled vehicles, use less road space and do not contribute to congestion get penalised whilst 4 wheel motorist whose vehicles use under 100g/km are exempt from road tax

29 Apr 2008

Fun With FreeBSD and gmirror

Filed under: General — Ben @ 20:49

A while ago I moved a lot of my stuff from a very ancient box to a quite new one. For some reason the new one has three disks in it, and so we (that is the ultra-patient Lemon and me) decided to mirror two of them. Not really having need of a third enormous disk it was left spare for now (possibly this was unwise in retrospect).

Since I run FreeBSD on my server boxes, we used gmirror. Being adventurous, we also decided we were going to mirror the root partition - slightly nerve-wracking, because when FreeBSD boots, it boots from the (unmirrored) root partition. But the theory is this works fine with mirrored disks.

So, we had three disks, which FreeBSD saw as ad4 (ata2-master), ad5 (ata2-slave) and ad6(ata3-master). We figured that ad4 and ad6 should be the mirrors, since they are on different controllers. So that’s what we did and it all works fine.

Fast forward several months and its time to upgrade the kernel. We’re moving from FreeBSD 6.x to FreeBSD 7.x, so its slightly nerve-wracking, but I do what I always do, which is to build the system from source, following the time-honoured

1. `cd /usr/src' (or to the directory containing your source tree).
2. `make buildworld'
3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
[steps 3. & 4. can be combined by using the "kernel" target]
5. `reboot’ (in single user mode: boot -s from the loader prompt).
6. `mergemaster -p’
7. `make installworld’
8. `make delete-old’
9. `mergemaster’
10. `reboot’

(btw, mergemaster -U is good medicine for step 9). Everything goes fine. Until I realise uname -a is still reporting we’re running FreeBSD 6.2! WTF?

Well, to make a long story short, for some reason the BIOS thinks ata2-slave(i.e. our “spare” disk!) is the “first” disk, and so this is what it boots off. Presumably during the build the system got installed on “disk 1″, whichever that happened to be (we didn’t actually do the base build ourselves). Then when mirroring was set up, our “disk 1″ didn’t match the BIOSes, and confusion reigned.

The happy ending to this story, though, is that

  • You can run FreeBSD 7 userland on a FreeBSD 6.2 kernel!
  • Switching the BIOS to boot off “disk 2″ (i.e. ata2-master) made everything work as it should

I am recording this episode not because I think it is very interesting but because I hope it’ll be useful to someone else.

26 Apr 2008

Do We Need Credentica?

Filed under: Anonymity, Crypto, Open Source, Privacy, Security — Ben @ 20:22

I read that IBM have finally contributed Idemix to Higgins.

But … I am puzzled. Everyone knows that the reason Idemix has not been contributed sooner is because it infringes the Credentica patents. At least, so says Stefan - I wouldn’t know, I haven’t checked. But it seems plausible that at least IBM think that’s true.

So, what’s changed? Have IBM decided that Idemix does not infringe? Or did Microsoft let them publish? Or what?

If its the former, then do others agree? And if its the latter, then in what sense is this open source? If IBM have some kind of special permission with regard to the patents, that is of no assistance to the rest of us.

It seems to me that someone needs to do some explaining. But if the outcome is that Idemix really is open source, then what is the relevance of Credentica?

Incidentally, I wanted to take a look at what it is that IBM have actually released, but there doesn’t seem to be anything there.

Can Phorm Intercept SSL?

Filed under: Crypto, Open Source, Privacy — Ben @ 18:24

Someone asked me to comment on a thread over at BadPhorm on SSL interception.

In short, the question is: can someone in Phorm’s position decrypt SSL somehow? The fear is driven by the existence of appliances that do just this. But these appliances need to do one of two special things to work.

The first possibility is where the appliance is deployed in a corporate network to monitor traffic going from browsers inside the corporation to SSL servers outside. In this case, what you do is you have the SSL appliance act as a CA, and you install its CA certificate in each browser’s store of trusted CAs. Then when the appliance sees an SSL request go past it quickly creates (some would say “forges”) a certificate for the server the request is destined for and instead of routing the connection on to the real server, instead answers it itself, using the newly created certificate. Because the browser trusts the appliance’s CA this all looks perfectly fine and it will proceed without a warning. The appliance then creates an outgoing connection to the real server and acts as a proxy between the browser and server, thus getting access to the plaintext of the interaction.

I’d note in passing that in Netronome’s diagram they show a “trust relationship” between the webserver and the SSL appliance. This is not correct. There need be no relationship at all between the webserver and the appliance - indeed it would be fair to say that many a webserver operator would view what the appliance is doing as downright sneaky. Or dishonest, even.

But, in any case, inside the corporation this behaviour seems fair enough to me - they’re paying for the browser, the machine it runs on, the network connection and the employee’s time. I guess they have a right to see the data.

Could Phorm do this? Well, they could try to persuade anyone stupid enough to install a CA certificate of theirs in their browser, and then yes, indeed, this trick would work for them. More of the story: don’t install such certificates. Note that last time I looked if you wanted to register to do online returns for VAT you had to install one of these things. Oops!

Or, they could get certified as a CA and get automatically installed in everyone’s browser. I’m pretty sure, however, that such a use of a CA key would find them in breach of the conditions attached to their certification.

So, in short, Phorm can only do this to people who don’t understand what’s going on - i.e. 99% of Internet users. But not me.

The second scenario is to deploy the SSL interception appliance at the webserver end of the network (at least, this is how its usually done), and have it sniff incoming connections to the webserver. However, to break these connections it needs to have a copy of the webserver’s private key. I’m reasonably confident that the vast majority of webserver operators will not be handing over their private keys to Phorm, so even “99%” users are safe from this attack.

By the way, if you want to see this one in action, then you can: the excellent network sniffer, Wireshark, can do it. Full instructions can be found here. No need to buy an expensive appliance.

25 Apr 2008

Yet Another Version Control System (and an Apache Module)

Filed under: Distributed stuff, Open Source — Ben @ 22:32

I recently finished off mod_digest for Canonical. To you: the guys that make Ubuntu.

In the process I was forced to use yet another distributed version control system, Bazaar. Once I’d figured out that the FreeBSD port was devel/bazaar-ng and not devel/bazaar, I quite liked it. All these systems are turning out to be pretty much the same, so it’s the bells and whistles that matter. In the case of Bazaar the bell (or whistle) I liked was this

$ bzr push
Using saved location: sftp://ben-links@bazaar.launchpad.net/~ben-links/apache-mod-digest/bensbranch/

Yes! In Monotone, I’m permanently confused about branches and repos and, well, stuff. Mercurial makes me edit a config file to set a default push location. Bazaar remembers what I did last time. How obvious is that?

23 Apr 2008

Why You Should Always Use End-to-End Encryption

Filed under: Anonymity/Privacy, Crypto, Privacy, Security — Ben @ 17:46

A Twitter user has had all her private messages exposed to the world. This is one of the reasons I try to avoid sending private messages (at least, ones that I would like to remain private) over any system that does not employ end-to-end encryption.

At least then my only exposure is to my correspondent, not the muppets that run the messaging service I used.

One service this poor unfortunate has done for the world, though, is to provide an excellent example of why you should use cryptography routinely: you need not have any more to hide than your embarrassment.

Incidentally, I am going to stop using the combined tag “Anonymity/Privacy” after this post - clearly they are not always both applicable.

Phorm Legal Analysis

Filed under: Anonymity/Privacy, Security — Ben @ 17:37

FIPR’s Nick Bohm has written a fascinating legal analysis of Phorm’s proposed system. Its nice that RIPA’s effects are not all bad, but it turns out that, in Nick’s opinion, Phorm are on the hook for a number of other illegal acts under various acts…

  • The Regulation of Investigatory Powers Act 2000
  • The Fraud Act 2006
  • The Data Protection Act 1998

He also beats up Simon Watkin of the Home Office (well-known in UK privacy circles for spending a great deal of energy trying to persuade us all that RIPA [then known as RIP] was going to be alright, really), for a note he wrote which suggested that Phorm’s business model was just fine under RIPA. Simon stays true to form by pointing out that the note wasn’t actually advice, and was not based on paying any attention at all to what Phorm were actually proposing. One has to wonder, then, what the point of writing it was?

Perhaps more disturbingly, Nick also talks about what my be the first attempt at enforcement against Phorm. Not surprisingly, the police say they’re too busy and it’s the Home Office’s problem and the Home Office say its not their job to investigate offences under RIPA. Isn’t it lucky, then, that we are doing their investigating for them?

I’m also pleased to see that Nick supports my view that the consent of both the user and the web server must be obtained for Phorm’s interception to be legal under RIPA

RIPA s3(1) makes it lawful if the interception has the consent of both
sender and recipient (or if the interceptor has reasonable grounds for believing
that it does). This raises the question of whose consent is required for the
interception of communications of those using web browsers.

I’m also intrigued by Nick’s analysis of Phorm’s obligation under the Data Protection Act. Where sensitive personal data is processed by Phorm, then the user’s consent must be obtained. Nick argues that Phorm will see information relating to

• their racial or ethnic origin,
• their political opinions,
• their religious or similar beliefs,
• whether they are members of a trade union,
• their physical or mental health or condition,
• their sexual life,
• the commission or alleged commission by them of any offence, or
• any proceedings for any offence committed or alleged to have been
committed by them, the disposal of such proceedings or the sentence of
any court in such proceedings

It occurs to me that Nick has missed a trick here: the user might also view sensitive data relating to a third party - for example, they might participate in a closed web forum where, say, sexual preferences are discussed. In this case, it seems to me, the consent of that third party would need to be obtained by Phorm.

20 Apr 2008

Oyster is Toast

Filed under: Crypto, Security — Ben @ 12:55

The MiFare stream cipher, as used in Oyster cards, has been comprehensively cracked. The researchers claim they can recover the key in well under 5 minutes after observing a single transaction.

When will people learn that making up your own ciphers is a fantastically bad idea?

16 Apr 2008

Nice Review of Caja

Filed under: Capabilities, Open Source, Programming, Security — Ben @ 1:41

Tim Oren posted about Caja.

…this adds up to a very good chance that something that’s right now fairly obscure could turn into a major force in Web 2.0 within months, not years. Because Caja modifies the de facto definition of JavaScript, it would have an immediate impact on any scripts and sites that are doing things regarded as unsafe in the new model. If you’ve got a Web 2.0 based site, get ready for a project to review for ‘Caja-safety’. If the Caja model spreads, then the edges of the sandbox are going to get blurry. Various users and sites will be able to make choices to allow more powerful operations, and figuring out which ones are significant and allow enhanced value could be a fairly torturous product management challenge, and perhaps allow market entry chances for more powerful forms of widgets and Facebook-style ‘apps’.

End of message.

6 Apr 2008

Conflicting Roles

Filed under: Identity Management, Security — Ben @ 23:51

Pamela Dingle writes about the problems of people having conflicting roles. Funnily enough I’m working on a paper about roles, too, but more on that later. Right now I wanted to observe that the problem she describes

There is no simple way to say that John is a broker 100% of the time, but 50% of the time he represents Client A and only Client A, and the other 50% he solely represents Client B. There is no way to represent mutual exclusivity of roles in a single user profile (that I’m aware of).

can handled in an interesting way in SE-Linux: there you can make the rule that once the user (or rather, a program acting on behalf of the user) has accessed any resource corresponding to Client A he is no longer allowed to access resources corresponding to Client B, and vice versa. Of course, leaping from this to the idea that you’ve built a real Chinese Wall between the two clients is falling foul of one of the fallacies of DRM: of course the user can find ways to transport data across that wall. But, nevertheless, SE-Linux is a system in which it is possible to express such policies.

31 Mar 2008

More Bullshit from Phorm

Filed under: Anonymity/Privacy, Digital Rights, Security — Ben @ 14:54

Phorm continue to sob that us whining privacy advocates are misrepresenting their system

Phorm’s chairman and chief executive, Kent Ertugrul, said yesterday the firm was the victim of misinformation. “What is so strange about this is that if you were to put on a board what we do and what has been written about us and map the two, you would find there is very little correlation,” he said.

I’d be more than happy to compare what I’ve said to what their system actually does, only … when the Open Rights Group nominated me to be briefed by Phorm (in my capacity as both a director of ORG and a subject matter expert) they declined, on the basis that I work for a competitor, despite my assurance that I would not be acting for Google in any way, as is always the case when I do stuff for ORG. But, hey, trust is a one-way street, apparently, if you are Phorm - as one of the surveilled, I must trust them, but that’s no reason they should trust me, is it?

Strangely they were quite happy to brief two of my colleagues in detail, without any NDA - and my colleagues are planning to produce a full, public report of that briefing. With a bit of luck, they’ll have addressed all my concerns, but who knows? I wasn’t there to assist in that process.

Interestingly, they go on to say

“What we would like to do is issue a challenge to the privacy community to select some of their most technically savvy representatives and form an inspection committee. We would be delighted, on a recurring basis, to give those people the ability to spot inspect what it is we do.”

which rather emphasizes one of the core problems with their system: it requires everyone to trust that all this data they have gathered without consent is actually handled as they claim it is handled.

I do hope Phorm will be paying the going rate for this valuable service - but probably I won’t find out because I expect that, despite my obvious qualifications, I will be excluded from such a group. It wouldn’t do to have anyone too expert looking at their system, after all.

30 Mar 2008

Microsoft Implement The Evil Bit

Filed under: Anonymity/Privacy, Security — Ben @ 18:41

Thanks to the Shindig mailing list, I’ve just noticed this gem from Microsoft.

The essence here is that third party sites inside frames might invade your privacy by setting cookies, so IE6, by default, doesn’t let them set cookies. But, if they promise to be good, then it will allow them to be bad. Isn’t that marvellous?

What I think is particularly excellent about Microsoft’s support article is that they tell you how to suppress the behaviour by setting an appropriate P3P policy … but they don’t tell you what this policy really means, nor suggest that you should only set the policy if you actually conform to it.

Of course, you can tell it’s a Microsoft protocol because it takes 21 bytes to do what the original proposal could do in a single bit.

25 Mar 2008

Federated Messaging Meets Federated Identity

Filed under: Distributed stuff, Identity Management — Ben @ 23:51

XMPP, OAuth and OpenID. Social networking in real-time. Interesting. Peter Saint-Andre thinks we should talk about it.

Sign up here.

24 Mar 2008

Fun With Dot

Filed under: Programming — Ben @ 14:59

As I’ve mentioned before, people don’t really talk much about the experience of writing and debugging code, so here’s another installation in my occasional series on doing just that.

Over the Easter weekend the weather has been pretty horrible, so, instead of having fun on my motorbike, I’ve been amusing myself in various ways: trying to finish up a paper I started last year, doing further work on OpenSSL and Deputy, cooking, playing with Tahoe (on which more later), updating my FreeBSD machines, and messing around with Graphviz.

Graphviz is one of my favourite toys. Basically, it lets you specify how a bunch of things are connected, and then it will draw them for you. A project I’d long had in my head was to take all the RFCs, work out which ones reference which other ones and have Graphviz draw it for me. Getting the data turned out to be pretty easy, but unfortunately the resulting dataset proves to be too much for poor old Graphviz, exposing all sorts of bugs in its drawing engine, which led to core dumps and/or complete garbage in the output files. Shame, early experiments promised some quite pretty output. Anyway, after banging my head against that for many hours, I gave up and instead did something I do every few months: got my various FreeBSD machines up-to-date. As part of that process, I had to look at the stuff that FreeBSD runs at startup, configured in /etc/rc.conf (and /etc/defaults/rc.conf), and actually done by scripts in /etc/rc.d and /usr/local/etc/rc.d.

This reminded me that these scripts expose their dependencies in comments, like this (from /etc/rc.d/pfsync)

# PROVIDE: pfsync
# REQUIRE: root FILESYSTEMS netif

So, I thought it would be fun to graph those dependencies - then at least I’d have one pretty thing to show for the weekend. Then, since it only took 15 minutes to do, I thought it might make an interesting subject for a post on how I go about coding such things.

So, first things first, I like some instant gratification, so step one is to eat the rc files and see if I can parse them. I wasn’t quite sure if /etc/rc.d had subdirectories, but since I had some code already to read all files in a directory and all its subdirectories (from my failed attempt at the RFCs) I just grabbed that and edited it slightly:

sub findRCs {
    my $dir = shift;

    local(*D);
    opendir(D, $dir) || croak "Can't open $dir: $!";
    while(my $f = readdir D) {
	next if $f eq '.' || $f eq '..';
	my $file="$dir/$f";
	if(-d $file) {
	    findRCs($file);
	    next;
	}
	readRC($file);
    }
}

This will call readRC for each file in the provided directory. My first version of readRC looked like this:

sub readRC {
    my $file = shift;

    my $rc = read_file($file);

    my($provide) = $rc =~ /^\# PROVIDE: (\S+)$/m;
    croak "Can't find PROVIDE in $file" if !$provide;

    print "$file: $provide\n";
}

Note that I assume that each file PROVIDEs only one thing, since I match \S+ (i.e. 1 or more non-whitespace characters), and force the matched string to span a whole line. This starts off well

/etc/rc.d/accounting: accounting
/etc/rc.d/amd: amd
/etc/rc.d/addswap: addswap
.
.
.

but ends

Can't find PROVIDE in /etc/rc.d/NETWORKING at ./graph-rc.pl line 13
main::readRC('/etc/rc.d/NETWORKING') called at ./graph-rc.pl line 30
main::findRCs('/etc/rc.d') called at ./graph-rc.pl line 35

oops. If we look at the offending file, we see

# PROVIDE: NETWORKING NETWORK
# REQUIRE: netif netoptions routing network_ipv6 isdnd ppp
# REQUIRE: routed mrouted route6d mroute6d resolv

OK, so it provides two things, it seems. Fair enough, I can fix that, I just have to elaborate the matching slightly

my($provide) = $rc =~ /^\# PROVIDE: (.+)$/m;
croak “Can’t find PROVIDE in $file” if !$provide;

my @provide = split /\s/,$provide;

print “$file: “, join (’, ‘,@provide), “\n”;

In other words, match everything after PROVIDE: and then split it on whitespace. Notice that this file also has multiple REQUIRE lines - lucky I noticed that, it could easily have escaped my attention. Anyway, after this modification, I can read the whole of /etc/rc.d. Now I need to match the requirements, which I do like this

my(@lrequire) = $rc =~ /^# REQUIRE: (.+)$/mg;
my @require = split /\s/, join(' ', @lrequire);

Another test, just printing what I extracted (print ' ', join (', ',@require), "\n";) and this seems to work fine. So far I’ve only been testing with /etc/rc.d, but now I’m almost ready to start graphing, I also test /usr/local/etc/rc.d

Can't find PROVIDE in /usr/local/etc/rc.d/sshd_localhost.sh at ./graph-rc.pl line 13
main::readRC('/usr/local/etc/rc.d/sshd_localhost.sh') called at ./graph-rc.pl line 35
main::findRCs('/usr/local/etc/rc.d') called at ./graph-rc.pl line 40

OK, so this is a very old rc file of my own and it has no require/provides stuff. In fact, it totally departs from the spec. Whatever … I decide to just skip files that don’t include REQUIRE

    if($rc !~ /PROVIDE/) {
	print STDERR "Skipping $file\n";
	return;
    }

A quick test confirms that it only skips that one file, and now everything works. OK, so time to graph! All I need to do is generate a file in a format Graphviz can read, which is amazingly easy. First I have to output a header

print "digraph rcs {\n";
print " node [fontname=\"Courier\"];\n”;

then a line for each dependency

    foreach my $p (@provide) {
	foreach my $r (@require) {
	    print "  $r -> $p; \n";
	}

and finally a trailer

print "}\n";

This produces a file that looks like this

digraph rfcs {
  node [fontname="Courier"];
  mountcritremote -> accounting;
  rpcbind -> amd;
  ypbind -> amd;
  nfsclient -> amd;
  cleanvar -> amd;
.
.
.
}

which I can just feed to dot (one of the Graphviz programs), like so

dot -v -Tpng -o ~/tmp/rc.png /tmp/xx

and I get a lovely shiny graph. But while I’m admiring it, I notice that ramdisk has a link to itself, which seems a bit rum. On closer inspection, /etc/rc.d/ramdisk says

# PROVIDE: ramdisk
# REQUIRE: localswap

which doesn’t include a self-reference. Odd. Looking at the output from my script I notice

ramdisk -> ramdisk-own;

Guessing wildly that dot doesn’t like the “-”, I modify the output slightly

    foreach my $p (@provide) {
	foreach my $r (@require) {
	    print "  \"$r\" -> \"$p\"; \n";
	}
    }
}

and bingo, it works. Putting it all together, here’s the final script in full

#!/usr/bin/perl -w

use strict;
use File::Slurp;
use Carp;

sub readRC {
    my $file = shift;

    my $rc = read_file($file);

    if($rc !~ /PROVIDE/) {
	print STDERR "Skipping $file\n";
	return;
    }

    my($provide) = $rc =~ /^\# PROVIDE: (.+)$/m;
    croak "Can't find PROVIDE in $file" if !$provide;
    my @provide = split /\s/, $provide;

    my(@lrequire) = $rc =~ /^# REQUIRE: (.+)$/mg;
    my @require = split /\s/, join(' ', @lrequire);

    foreach my $p (@provide) {
	foreach my $r (@require) {
	    print "  \"$r\" -> \"$p\"; \n";
	}
    }
}

sub findRCs {
    my $dir = shift;

    local(*D);
    opendir(D, $dir) || croak "Can't open $dir: $!";
    while(my $f = readdir D) {
	next if $f eq '.' || $f eq '..';
	my $file="$dir/$f";
	if(-d $file) {
	    findRCs($file);
	    next;
	}
	readRC($file);
    }
}

print "digraph rfcs {\n";
print "  node [fontname=\"Courier\"];\n”;

while(my $dir=shift) {
    findRCs($dir);
}

print “}\n”;

and running it

./graph-rc.pl /etc/rc.d /usr/local/etc/rc.d > /tmp/xx
dot -v -Tpng -o ~/tmp/rc.png /tmp/xx

And finally, here’s the graph. Interesting that randomness is at the root!

RC dependencies

20 Mar 2008

Am I Reassured?

Filed under: Open Source — Ben @ 10:09

Mike Jones (of Microsoft) tells me I was wrong to be worried about Microsoft’s Open Specification Promise. I wasn’t actually that worried, but now I am.

He says

The “analysis” tries to insinuate that since Microsoft doesn’t promise that future revisions of specifications covered by the Open Specification Promise will be automatically covered unless Microsoft is involved in developing them, that it’s not safe to rely on the OSP for current versions either. This is of course false, as the OSP is an irrevocable promise that Microsoft will never sue anyone for using any of the covered specifications (unless they sue Microsoft for using the same specification, which is a normal exception in all such non-assertion covenants).

Clearly the point is not that current specifications might stop being covered. The problem is that if future versions of the specs are not covered then it will become irrelevant that current ones are - there’s no point in implementing a standard that no-one uses anymore. And given Microsoft’s track record in the area of extending specifications until no-one can implement them, this seems like a very real risk.

He then points to a response in the context of OOXML that is supposed to further reassure. But it does the opposite

This section points out that the OSP only applies to listed versions of covered specifications. True, except that we have already committed to extending it to ISO/IEC DIS 29500 when it is approved in our filing with ISO/IEC. For ODF, IBM in their ISP takes the identical approach. Strange how things that seem appropriate for ODF are not appropriate for Open XML.

In other words, Microsoft can do exactly what I am concerned about, except that in the case of OOXML (which I really don’t care about) they’ve promised not to. Nice for word processors, perhaps. Not so nice for security people, who are covered by no such promise.

OSP covers specifications not code

Not true. The OSP is a promise to not assert patents that are necessarily infringed by implementations of covered specifications. Like all similar patent non-asserts (including the Sun and IBM versions for ODF) the promise covers that part of a product that implements that specification (and not other parts that have nothing to do with the specification). While the Sun covenant is silent about conformance to the specification, the OSP allows implementers the freedom to implement any (or all) parts of a covered specification and to the extent they do implement those portions (also known as conform to those parts) they are covered by the promise for those parts. Contrast that to the IBM pledge that requires total conformance and so programming errors or absence of something required by the spec (but not by an implementer’s product) means that the promise is totally void for that product.

I just don’t get this. It starts with “not true” but then goes on to confirm that it is true! That is, the code is only usable insofar as it is used to implement a covered specification. Programming errors would void their promise just like it does IBM’s. And similarly, re-use of the code for a different purpose would also not be covered. In other words, the specification is covered, not the code.

If Microsoft can’t coherently defend themselves against this analysis but still want us to believe it is incorrect, that seems cause for concern, don’t you think?

Interoperability

Despite Kim’s promise in his blog

That doesn’t mean it is trivial to figure out the best legal mecahnisms for making the intellectual property and even the code available to the ecosystem. Lawyers are needed, and it takes a while. But I can guarantee everyone that I have zero intention of hoarding Minimal Disclosure Tokens or turning U-Prove into a proprietary Microsoft technology silo.

Like, it’s 2008, right? Give me a break, guys!

I’ve now heard through several different channels that Microsoft want to “ensure interoperability”. Well. Interoperability with what, I ask? In order for things to be interoperable, they must adhere to a standard. And for Microsoft to ensure interoperability, they have to both licence the intellectual property such that it can only be used in conformance to that standard and they have to control the standard.

I don’t know about you, but that sure sounds like a “proprietary Microsoft technology silo” to me.

18 Mar 2008

Pork Chops in Cider

Filed under: Recipes — Ben @ 13:33

This recipe was originally cooked for me by my friend Honk. Well, something somewhat like it was.

pork chops
garlic
mixed herbs
onions
olive oil
butter
mushrooms
more garlic
cider
cooking apples
cream

Smear the pork chops with crushed garlic, mixed herbs, salt and pepper. I’m lazy, so I only do one side. Grill them so they’re nicely browned on each side but not cooked all the way through. Starting with them slightly frozen might help.

Meanwhile, roughly chop the onions and cook them in olive oil until sweet. Add butter, sliced mushrooms, more crushed garlic, salt and pepper. Be generous with the butter. Cook the mushrooms very gently until they’re soft and laden with butter. Add cider, quarter of a can at a time, reducing it to almost nothing each time. Somewhere in there, add sliced cooking apple. When the apple is nearly soft and you still have some cider left, add the grilled pork chops to this mess. Cook them in the final reduction of cider. Once that’s done, turn off the heat and add cream.

Eat. And feel fat.

For guidance for 4 pork chops I used four flat mushrooms, three 750 cl cans of cider and two cooking apples. Cream I leave to your conscience. Obviously the chops need some fat on them or this will be totally boring. In fact, I lust after the chops I once saw in The Ginger Pig which were over half fat. Yum.

Sauteed potatoes are good with this. And peas if you’re lazy. Spinach if less so.

13 Mar 2008

Microsoft’s Open Specification Promise

Filed under: Open Source, Programming — Ben @ 20:11

The Software Freedom Law Centre has published an analysis of the OSP. I don’t really care whether the OSP is compatible with the GPL, but their other points are a concern for everyone relying on the OSP, whether they write free software or not.

Bad Phorm?

Filed under: Anonymity/Privacy, Security — Ben @ 14:28

As anyone even half-awake knows, there has been a storm of protest over Phorm. I won’t reiterate the basic arguments, but I am intrigued by a couple of inconsistencies and/or misleading statements I’m spotting from Phorm’s techies.

In an interview in The Register, Phorm’s “top boffin” Marc Burgess says

What the profiler does is it first cleans the data. It’s looking at two sets of information: the information in the request that’s sent to the website and then information in the page that comes back.

From the request it pulls out the URL, and if that URL is a well known search engine such as Google or Yahoo! it’ll also look for the search terms that are in the request.

And then from the information returned by the website, the profiler looks at the content. The first thing it does is it ignores several classes of information that could potentially be sensitive. So there’s no form fields, no numbers, no email addresses (that is something containing an “@”) and anything containing a title like Mr or Mrs.

he says “there’s no form fields”. But this is in the response from the webserver. Form fields in the request sent to the webserver are fair game, it seems. In other words, Phorm are quite happy to spy on what you type, but will ignore form fields sent to you by the server - well, that’s big of them: those fields are usually empty. It’s interesting that many people have picked this up as a contradiction (that is, how can there be no form fields if you are looking at search terms, which are entered into a form field?) - but it has been carefully worded so that it is not contradictory, just easy to misinterpret.

Phorm can completely adhere to this public statement and yet still look at everything you typed. Note also that they only talk about filtering senstive data in the response and not in the request. So nothing, it seems, is really sacred.

Incidentally, they are silent about what they do with the body of the request (usually when you submit a form, the fields end up in the body rather than the URL). That fills me with curiosity.

Even ORG swallow this bit of propaganda (from ORG’s post)

Phorm assigns a user’s browser a unique identifying number, which, it is claimed, nobody can associate with your IP address, not even your ISP.

Of course, this is nonsense. The ISP can easily associate the identifying number with your IP address - all they have to do is watch the traffic and see which IP address sends the cookie with the Phorm ID in it. In fact, they could probably use the Phorm box for this, since it already sees all the data.

and Phorm’s CEO, Kent Ertegrul, again in the interview with The Register

It’s important to understand the distinction between actually recording stuff and concluding stuff. All of our systems sit inside BT’s network. Phorm has no way of going into the system and querying “what was cookie 1000062 doing?”. And even if we did we have no way of knowing who 1000062 was. And even if we did all we could pull out of it is product categories. There’s just no way of understanding where you’ve been, what you’ve done, what you’ve searched for.

They say this, but we have to take their word for it. Obviously the fact it sits inside BT’s network is no barrier to them connecting to it. Clearly they could just look at the traffic traversing the system and know exactly what cookie 1000062 is doing. And which IP address is doing it, which doesn’t tell you who is doing it, but certainly narrows it down. Analysis of the data will almost certainly allow identification of the individual concerned, of course.

Not, of course, that taking people’s word for their privacy practices is unacceptable - it is pretty much unavoidable. What I object to is Phorm’s attempts to convince us that it is impossible for them to misbehave. Of course, it is not.

Now let’s take a look at BT’s FAQ

Is my data still viewed when I am not participating?

No, when you don’t participate or switch the system off — it’s off. 100%. No browsing data whatsoever is looked at or processed by BT Webwise. . We should be clear: the Phorm servers are located in BT’s network and browsing data is not transmitted outside. Even if you are opted out, websites will still show you ads (as they do now) but these will not be ads from the Phorm service and they will not be more relevant to your browsing. In addition, you will also not get extra protection from fraudulent websites.

This is just obviously a lie. Since opt-out is controlled by a cookie, the system must look at your browsing data in order to determine whether you have the opt-out cookie or not. Naughty BT.

Furthermore, it is difficult to imagine how they could architect a system where your data did not traverse some box doing interception, though it may, of course, decide not to look at that data. But once more we’d have to take their word for it. How can we ever be sure they are not? Only by having our data not go to the box at all.

Talk Talk say they are going to architect their system in this way, somewhere in the comments on this post. I await details with interest - I can’t see how they can do it, except by either pushing the traffic through some other interception box, which doesn’t really change the situation at all, or by choosing whether to send to the Phorm box on the basis of IP address - which does not identify the user, so, for example, I could find myself opted-in by my children, without my knowledge!

All these worries apply to the system working as intended. What would happen if the Phorm box got pwned, I dread to think. I hope they’ve done their homework on hardening it! Of course, since they have “no access to the system”, it’ll be interesting to see how they plan to keep it up-to-date as attacks against it evolve.

11 Mar 2008

RFC 5155

Filed under: Anonymity/Privacy, Crypto, Distributed stuff — Ben @ 11:43

After nearly 4 years of mind-bending minutiae of DNS (who would’ve thought it could be so complicated?), political wrangling and the able assistance of many members of the DNSSEC Working Group, particularly my co-authors, Roy Arends, Geoff Sisson and David Blacka, the Internet Draft I started in April 2004, “DNSSEC NSEC2 Owner and RDATA Format (or; avoiding zone traversal using NSEC)” now known as “DNS Security (DNSSEC) Hashed Authenticated Denial of Existence” has become RFC 5155. Not my first RFC, but my first Standards Track RFC. So proud!

Matasano Chargen explain why this RFC is needed, complete with pretty pictures. They don’t say why its complicated, though. The central problem is that although we all think of DNS as a layered system neatly corresponding to the dots in the name, it isn’t.

So, you might like to think, and it is often explained this way, that when I look up a.b.example.com I first ask the servers for . who the nameserver for com is. Then I ask the com nameservers where the nameservers for example.com is, who I then ask for the nameservers for b.example.com and finally ask them for the address of a.b.example.com.

But it isn’t as easy as that. In fact, the example.com zone can contain an entry a.b.example.com without delegating b.example.com. This makes proving the non-existence of a name by showing the surrounding pair rather more challenging. The non-cryptographic version (NSEC) solved it by cunningly ordering the names so that names that were “lower” in the tree came immediately after their parents. Like this:

a.example.com
b.example.com
a.b.example.com
g.example.com
z.example.com

So, proving that, say, d.example.com doesn’t exist means showing the pair (a.b.example.com, g.example.com). Note that this pair does not prove the nonexistence of b.example.com as you might expect from a simple lexical ordering. Unfortunately, once you’ve hashed a name, you’ve lost information about how many components there were in the name and so forth, so this cunning trick doesn’t work for NSEC3.

It turns out that in general, to prove the nonexistence of a name using NSEC you have to show at most two records, one to prove the name itself doesn’t exist, and the other to show that you didn’t delegate some parent of it. Often the same record can do both.

In NSEC3, it turns out, you have to show at most three records. And if you can understand why, then you understand DNS better than almost anyone else on the planet.

Next Page »

Powered by WordPress

Close
E-mail It