Ben Laurie - The World Without “Identity” or “Federation” is Already Here
My friend Alec Muffett thinks we should do away with “Big I” Identity. I’m all for that … but Alec seems to be quite confused.
Firstly, his central point, that all modern electronic identity requires the involvement of third parties, is just plain wrong. OpenID, which he doesn’t mention, is all about self-asserted identity - I put stuff on webpages I own and that’s my identity. Cardspace, to the extent it is used at all, is mostly used with self-signed certificates - I issue a new one for each site I want to log in to, and each time I visit that site I prove again that I own the corresponding private key. And, indeed, this is a pretty general theme through the “user-centric” identity community.
Secondly, the idea that you can get away with no third party involvement is just unrealistic. If everyone were honest, then sure, why go beyond self-assertion? But everyone is not. How do we deal with bad actors? Alec starts off down that path himself, with his motorcycling example: obviously conducting a driving test on the spot does not scale well - when I took my test, it took around 40 minutes to cover all the aspects considered necessary to establish sufficient skill, and I’d hesitate to argue that it could be reduced. The test used to be much shorter, and the price we paid was a very high death rate amongst young motorcyclists; stronger rules have made a big inroads on that statistic. It is not realistic to expect either me or the police to spend 40 minutes establishing my competence every time it comes into question. Alec appears to be recognising this problem by suggesting that the officer might instead rely on the word of my local bike club. But this has two problems, firstly I am now relying on a third party (the club) to certify me, which is exactly counter to Alec’s stated desires, and secondly, how does one deal with clubs whose only purpose is to certify people who actually should not be allowed to drive (because they’re incompetent or dangerous, for example)?
The usual answer one will get at this point from those who have not worked their way through the issues yet is “aha, but we don’t need a central authority to fix this problem, instead we can rely on some kind of reputation system”. The trouble is no-one has figured out how you build a reputation system in cyberspace (and perhaps in meatspace, too) that is not easily subverted by people creating networks of “fake” identities purely in order to boost their own reputations - at least, not without some kind of central authority attesting to identity.
Yet another issue that has to be faced is what to do about negative attributes (e.g. “this guy is a bad risk, don’t lend him money because he never pays it back”). No-one is going to willingly make those available to others. Once more, we end up having to invoke some kind of authority.
Of course, there are many cases where self-assertion is perfectly fine, so I have no argument with Alec there. And yes, there is a school of thought that says any involvement with self-issued stuff is a ridiculous idea, but you mostly run into that amongst policy people, who like to think that we’re all too stupid to look after ourselves, and corporate types who love silos (we find a lot of those in the Liberty Alliance and the ITU and such-like places, in my experience).
But the bottom line is that a) what he wants is insufficient to completely deal with the problems of identity and reputation and b) it is nothing that plenty of us haven’t been saying (and doing) all along - at least where it works.
Once you’ve figured that out, you realise how wrong
I am also here not going to get into the weirdness of Identity wherein the goal is to centralise your personal information to make management of it convenient, and then expend phenomenal amounts of brainpower implementing limited-disclosure mechanisms and other mathematica, in order to re-constrain the amount of information that is shared; e.g. “prove you are old enough to buy booze without disclosing how old you are”. Why consolidate the information in the first place, if it’s gonna be more work to keep it secret henceforth? It’s enough to drive you round the twist, but it’ll have to wait for a separate rant.
is. Consolidation is not what makes it necessary to use selective disclosure - that is driven by the need for the involvement of third parties. Obviously I can consolidate self-asserted attributes without any need for selective disclosure - if I want to prove something new or less revealing, I just create a new attribute. Whether its stored “centrally” (what alternative does Alec envision, I wonder?) or not is entirely orthogonal to the question.
Incidentally, the wit that said “Something you had, Something you forgot, Something you were” was the marvellous Nick Mathewson, one of the guys behind the Tor project. Also, Alec, if you think identity theft is fraud (as I do), then I recommend not using the misleading term preferred by those who want to shift blame, and call it “identity fraud” - in fraud, the victim is the person who believes the impersonator, not the person impersonated. Of course the banks would very much like you to believe that identity fraud is your problem, but it is not: it is theirs.
Ben Laurie - Petition Against Unfair Motorcycle Tax
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
Ben Laurie - Fun With FreeBSD and gmirror
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.
Ben Laurie - Do We Need Credentica?
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.
Ben Laurie - Can Phorm Intercept SSL?
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.
Ben Laurie - Yet Another Version Control System (and an Apache Module)
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?
Ben Laurie - Why You Should Always Use End-to-End Encryption
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.
Ben Laurie - Phorm Legal Analysis
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.
Ben Laurie - Oyster is Toast
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?
Ben Laurie - Nice Review of Caja
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.
Ben Laurie - Conflicting Roles
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.
Ben Laurie - More Bullshit from Phorm
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.
Ben Laurie - Microsoft Implement The Evil Bit
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.
Ben Laurie - Federated Messaging Meets Federated Identity
XMPP, OAuth and OpenID. Social networking in real-time. Interesting. Peter Saint-Andre thinks we should talk about it.
Sign up here.
Ben Laurie - Fun With Dot
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!
Ben Laurie - Am I Reassured?
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?
Ben Laurie - 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.
Ben Laurie - Pork Chops in Cider
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.
Ben Laurie - Microsoft’s Open Specification Promise
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.
Ben Laurie - Bad Phorm?
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.
Ben Laurie - RFC 5155
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.
Ben Laurie - Microsoft Buys Credentica
Kim and Stefan blog about Microsoft’s acquisition of Stefan’s selective disclosure patents and technologies, which I’ve blogged about many times before.
This is potentially great news, especially if one interprets Kim’s
Our goal is that Minimal Disclosure Tokens will become base features of identity platforms and products, leading to the safest possible intenet. I don’t think the point here is ultimately to make a dollar. It’s about building a system of identity that can withstand the ravages that the Internet will unleash.
in the most positive way. Unfortunately, comments such as this from Stefan
Microsoft plans to integrate the technology into Windows Communication Foundation and Windows Cardspace.
and this from Microsoft’s Privacy folk
When this technology is broadly available in Microsoft products (such as Windows Communication Foundation and Windows Cardspace), enterprises, governments, and consumers all stand to benefit from the enhanced security and privacy that it will enable.
sound more like the Microsoft we know and love.
I await developments with interest.
Ben Laurie - Users Are Stupid…
… and they won’t take sensible security decisions, so we have to dumb everything down for them. Or at least, that’s what we whine. So, I have to ask, WTF is this all about?
How is anyone supposed to figure out what to do now? Surely we know which of those three errors it was? So why are we giving the user such appallingly crap feeback?
And I can totally imagine how the conversation with Majestic’s webmaster is going to go…
Me: Hey, I got this error. Apparently you’re either using a CA that’s not in a list I’m not going to give to you, or you screwed up your server config so your certificate is incomplete, or you are a phisher and I’ve just given you my password, or you aren’t a phisher but your cert and website don’t match. Please fix it.
Webmaster: O RLY? Well, I’ve got this email that says your wine order is either in the post, not in the post, cancelled or coming to me instead. Laugh it up, big boy.
Ben Laurie - A Concrete Proposal
Kim wants to help, and Pat Patterson puts flesh on the bones of my proposal in an infocards context.
To summarise Pat’s proposal, what happens is you go to wherever you want to log in, you fetch your username/password for that site from your IdP, encrypted using the public key for that site. That way, only the IdP and the site know the password. I’m pretty impressed that this can be done without modifying the WS-* protocols, but there’s still a little work left to be done…
In particular, we’re presumably going to be migrating to this from an existing login - in the process we should change the password from whatever phishable nastiness was in use to a nice strong, random password. Or one derived from a master password and the site’s name. Failure to do this would not improve the phishing situation.
Also, if we use the latter scheme, we can eliminate the IdP and do the whole thing locally, using the master password. This gives you portability (without worrying about the grander problem of porting all credentials) for free.
And, of course, this all needs to happen without much work or comprehension on the part of the user. But it’s definitely a step in the right direction!
Ben Laurie - Not The Browser!
Kim correctly observes that the browser is not the place to be typing your password. Indeed. I should have mentioned that.
Clearly any mechanism that can be imitated by a web page is dead in the water. Kim also wants to rule out plugins, I take it, given his earlier reference to toolbar problems. I’m OK with that. We want something that only a highly trusted program can do. That’s been so central to my thinking on this I forgot to mention it. Sorry.
Ben Laurie - Get Real
Kim Cameron, bless him, manages to interpret one of my most diabolical hungover bits of prose ever. I am totally with him on the problem of pharming, but the reality is that the average Cardspace user authenticated with nothing better than a password (when they logged into Windows). Furthermore, if you are going to achieve portability of credentials, then you can either do it in dreamland, where all users carry around their oh-so-totally-secure bluetooth credential device, or you can do it in the real world, where credentials will be retrieved from an online store secured by a password. And yes, we’ll encourage people to make sure that’s a passphrase, and they don’t type it in in web cafes, and all that. And the corporate VPN types will use SAML and doohickeys with keypads. And maybe if they’re really smart the “online store” will actually be a USB stick and a backup split between a few of their best friends.
But we have a simple mission: protect that password.
If you believe the Cardspace UI can protect people’s credentials, then surely it can protect a password?
If it really can’t (that is, we cannot come up with UI that people will reliably identify and eschew all imitations), then how will we ever have a workable, scalable system that includes recovery of credentials after loss or destruction of their physical goods?
Ben Laurie - If You Have Cardspace, Why Use OpenID?
Kim Cameron writes about fixing OpenID’s phishing problems by using Cardspace. Certainly I agree that using strong authentication to the OpenID provider fixes the phishing problem - but if you have strong authentication, why bother to use OpenID at all? Why not strongly authenticate to the site you are really trying to log into, instead?
Of course, Cardspace is a pretty heavyweight solution for this, so perhaps that’s what Kim’s getting at? It also doesn’t work well if you have more than one machine - moving your credentials around is not something Cardspace does well.
In my view, there’s a sweeter spot for solving this problem than Cardspace (or OpenID, obviously) - and that is to do strong authentication based purely on a password. That way, you can use the same password everywhere, so no problem with moving between machines, but can still resist phishing attacks and don’t have to make yourself linkable across all sites. Obviously supporting this would be way easier than taking the whole of Cardspace on board, but would have all of the immediate advantages. Clearly it would get you nowhere with advanced identity management, but its not like we don’t already have protocols for that and nor does there seem to be much demand for it yet.
Ben Laurie - Wikileaks
The Guardian has a nice article about Wikileaks today. This was triggered by bizarre behaviour on the part of Bank Julius Baer’s lawyers, Lavely and Singer (“Attack Dogs of L.A. Law”), who asked Wikileaks to remove documents without specifying what documents or who their client was and then got an injunction to have the wikileaks.org domain deleted.
The documents are still available, of course.
One thing I should correct, though. The article says
Those behind Wikileaks include … Ben Laurie, a mathematician living in west London who is on the advisory board.
I’m not a mathematician (any more), and I’m not behind Wikileaks. I think its a good idea, and I did comment on an early design for the technical infrastructure (which, I must say, was cool), but I am otherwise uninvolved. Everyone thinks this is just a cunning ploy to distance myself from it, but really, its true.
Ben Laurie - OAuth
Pamela is freaked out by sites that gather all your logins. So am I. But this is exactly why a group of us got together to create OAuth. OAuth allows you to delegate access to your various accounts without revealing your username and password. All we need now is for all these sites to start using it.
ShmooCon News - Another year gone by...
A few quick notes:Thanks to all who handed in feedback forms this year. Your comments are incredibly important to us. If you forgot to hand them in, or have more to say, please email us at feedback at shmoocon dot org.
Videos and slides will be up soon. Now that the ShmooCon staff is starting to wake up, we'll get working on this post haste. It will take some time - but our goal is to be done with it by sometime next week.
Need help remembering the rest of your weekend? Photo sets are rapidly appearing on Flickr. Have fun with that.
A huge thank you to our Speakers, Sponsors, and Staff. You rock.
And finally - thanks go out to you, the attendee.
w00t indeed.
ShmooCon News - Some things of note...
Lost barcodes:If you have your transaction id you can regenerate your barcode. Otherwise, bringing id will be fine.
Metro Delays:
If you plan on getting to the conference by Metro this weekend, we strongly recommend you check their website for any service alerts before you travel. We are specifically concerned about this one detailing delays on the red, orange and blue lines for the weekend.
See you in a few days!
Ben Laurie - Caja in the News
It seems MySpace’s developer launch today is causing Caja to get splattered all over the place.
Ben Laurie - Eggonomics
So, Egg are shedding customers they think are a bad risk. I wonder what happens if this becomes fashionable? Since the worst offenders are in the habit of moving their debt from one free offer to the next, presumably whoever moves last will end up with the credit card equivalent of the sub-prime mortgage disaster. Buy Egg, sell HSBC!
Ben Laurie - Open Source Is Just Economics
A number of conversations I have had recently indicate to me that a lot of the world still doesn’t get what’s behind open source. It’s easy: economics.
The first thing you can trivially explain is why people work on open source at all. This has been a source of a vast amount of speculation, particularly irritatingly by sociologists. Ben Hyde has a fantastic list to which I will only add the explanation I love to hate: geek pride. We do it just to show off to each other.
Nope, it’s all bollocks - the motivation is simple: by solving your common problem together, you reduce your costs. There is absolutely no point in financing five different companies to produce five different products that don’t quite do what you want - far better to tweak the open source thing to do exactly what you need (often expressed as “scratching your itch” around the ASF).
Some people whine that, because this is an option open only to geeks, open source is not really available to completely open participation. Well, kinda. If you aren’t a geek yourself, you can always hire one. What do you mean, you don’t want to spend your money on free stuff? Why not? We all spend our time on it. Time that we could convert into money, if we so chose.
So why don’t we? Because participating in the open source projects we participate in is worth more to us, in purely monetary terms, in the long run. This is why I no longer have much to do with Apache: it does what I need. I have no itch to scratch.
This leads me into the second easily explainable fact. People complain that open source projects don’t care about users. It’s true. They don’t - they care about people who are participating in the costs of producing the software. If you aren’t contributing, why would your voice matter?
Of course, you have to be careful when applying these obvious truths to what you see around you. For example, the presence of companies like Red Hat in the market complicates analysis. They have their own set of economic drivers, including the needs of their customers, which they then apply to the calculation around their participation in various projects. As the reach of open source extends, so do end users actually start to get an indirect say in what happens. But it costs them. Money.
Back in the good old days, it was so much simpler. All it cost me then was time.
Ben Laurie - Caja, Shindig and OpenSocial
Its been a while since I wrote about Caja but we’ve been working hard on it and it has come along in leaps and bounds, thanks to my excellent team at Google.
Today I’m very pleased to be able to point you at a test gadget container which supports Cajoling of gadgets. This is based on the open source OpenSocial container, Shindig.
Here’s the announcement, and there’s also some documentation on how to get things working with Caja. We’ve even included a couple of malicious gadgets which are defeated by Caja.
Feedback, as always, welcome.
ShmooCon News - Speaker Selection Finalized
The bulk of the information is on our speakers page with more to come.Thanks to everyone who submitted.
Ben Laurie - Deputy, Delta and Type Checking in C
Another thing I never write about but am very interested in is static analysis. For the non-geeks amongst my readers, static analysis is all about looking at code to see what you can figure out about it. For example, you might try to find input values that cause a buffer overflow. Or you might check to see that strings are correctly escaped before being posted to a Web page (that is, the bug that is at the heart of cross-site scripting has been avoided).
Of course static analysis is usually done by programs, perhaps with the assistance of the programmer, rather than by people, so I am always on the look out for new approaches and new software. Unfortunately, as in many areas of academia, the gap between theory and practice is rather large so I do not find myself exactly overwhelmed with choice.
So far the only thing that I’ve been even a little happy with is Coverity. This still gets it wrong about half the time, but that’s a pretty tolerable ratio given how painful a manual audit would be. In contrast, some of the other tools I have tried over the years have false positive rates well over 99.9%.
Most of them just plain don’t work. Pretty much all of them are not supported. And those that are, like Coverity, cost a fortune.
If I was not a convert to the cause of static analysis, I would despair. As it is, I do occasionally feel tempted to sit down for a year or two and tackle the problem myself but sanity soon prevails and I put that idea off for another decade. So, I was happy to come across Deputy recently, after an animated thread or two on the Robust Open Source mailing list (which I am shocked to discover I have been on since it started, way back in 1998 - archives here and here).
Deputy attempts to provide type safety in C programmes. This is, of course, impossible … but it has a good attempt at it. Although ordinary programmers might not think so, to the academic type safety means enforcing things like array lengths, so our favourite C security problem, the buffer overflow, would be a thing of the past if we had typesafe programs.
Anyone who had read the code I wrote for safe stacks in OpenSSL or the module API in Apache 2.0 will know that I am a big fan of type safety in C. Both of these try to ensure that if you get confused about what type you should be using, you will get a compile-time failure. Unfortunately C provides the programmer with a plethora of ways to both deliberately and accidentally avoid any safety nets you might put out for him. The idea behind Deputy is to make it possible to do the type checking rather more rigorously. In order to allow this, you have to provide deputy with extra clues.
The syntax is a little idiosyncratic, but generally the annotation is quite straightforward, for example
void * (DALLOC(n) malloc)(size_t n);
would tell it that malloc is a memory allocator that returns n bytes of memory. Deputy catches many errors at compile time, but those it can’t it will attempt to catch at runtime instead, by injecting extra code to make sure pointers stay within bounds, for example. I haven’t got that far, though, because my benchmark for these projects is to use them on something real, like OpenSSL. I am pleased to report, though, that Deputy has so far built several OpenSSL source files without driving me completely crazy. But more on that later.
In the course of using Deputy I have been reminded of two things worth mentioning in passing. One is a trick we use in OpenSSL to do type checking. If you want to ensure that something is of type T, then you can write this
(1 ? x : (T)0)
weird, huh? How it works is that both sides of a ? : operator must have the same type, so if x is not of type T, then you will get a compile-time error. Very handy in macros, especially where you are abusing types heavily - for example when you are implementing a generic stack, but you wan to ensure that any particular stack consists only of one type of object (see safestack.h in OpenSSL for an example).
The other is delta. Delta is a very cute tool that cuts down a file with an “interesting” feature to a smaller one with the same feature. For example, suppose (as happened to me) I have an error that I can’t reproduce in a small example. Now what? Delta to the rescue. Today I had a problem with Deputy wanting me to add extra annotation that seems unnecessary. Small examples of essentially the same code did not show the same issue. What do do? Delta reduced the original offending source from 2424 lines to just 18 that produce the same bug. And it did it in about 5 minutes.
For interest, here are the 18 lines
typedef unsigned int __uint32_t;
typedef __uint32_t __size_t;
typedef __size_t size_t;
void *malloc(size_t);
void *memcpy(void * , const void * , size_t);
# 77 "mem.c"
static void * (DALLOC(n) *malloc_func)(size_t n) = malloc;
static void *default_malloc_ex(size_t num, const char *file, int line) {
return malloc_func(num);
}
static void *(*malloc_ex_func)(size_t, const char *file, int line) = default_malloc_ex;
void *CRYPTO_realloc_clean(void *str, int old_len, int num, const char *file, int line) {
void *ret = ((void *)0);
ret=malloc_ex_func(num,file,line);
if(ret) {
memcpy(ret,str,old_len);
}
}
Funnily enough delta was created to assist in debugging another static analysis system, Oink. So far, I’ve never used it for anything else.
Ben Laurie - Be Careful With The Social Graph
Bob Blakley is concerned that if we open up the social graph, then we’ll kill social networking (if I were you I’d skip the rather complicated and irrelevant analogy he kicks off with: to mangle my friend Jennifer Granick’s oft-given advice, we should talk about the thing itself and not what it is like). His core point is that its not OK for Scoble to move his relationship data from one system to another because he doesn’t own that data - it is jointly owned by him and those with whom he has relationships.
Whilst I agree that it may not be OK to move such data around, I think Bob is wrong about the details. Plus he picked a terrible example: it hardly matters what Scoble did with his friends list because anyone can already see it.
And this precisely illustrates what seems most important to me: when I share social data, I do so under certain conditions, both explicit and implict. What I care about, really, is that those conditions continue to be met. I don’t really mind who does the enforcing, so long as it is enforced. So, it seems to me that its OK to create the social graph, you just have to be exceedingly careful what you do with it.
This presents two, in my view, enormous technical challenges. The first is dealing with a variety of different conditions applying to different parts of the graph. Even representing what those conditions are in any usable way is a huge task but then you also need to figure out how to combine them, both when multiple conditions apply to the same piece of data (for example, because you figured it out twice in different ways) or when the combination of various pieces of data, each with its own conditions, yield something new.
Once you’ve done that you are faced with a much larger problem: working out what the implicit conditions were and enforcing those, too. The huge adverse reaction we saw to Facebook’s Beacon feature shows that such implicit conditions can be unobvious.
Anyway, the bottom line is that those in favour of the social graph tend to see it as some nodes, representing people, and edges, representing relationships. What they ignore is the vast cloud of intertwined agreements and understandings woven around all those edges and nodes. But those are absolutely vital to the social graph. Without them, as Bob says
Opening the social graph will destroy social networks, and turn them into sterile public spaces in which formation of meaningful and intimate relationships is not possible.
So, by all means, open the social graph but do it really carefully.
One thing I’ll note in passing: it is very common, in human relationships, to reveal far more than you are supposed to - under condition that the recipient of the revelation maintains absolute secrecy about it. For example, everyone knows that Alice is bonking Bob except Alice’s husband and Bob’s wife. This is because a series of “absolute secrecy” conditions and careful thought have neatly partitioned the world with respect to this piece of information. Usually. Should a good social graph emulate this?
Ben Laurie - Me-ville Versus The Global Village
Thanks to Adriana, I just came across an intriguing post on VRM. In it, two completely different versions of VRM are presented (he thinks he presented four, but I claim that the “vendor control” end of the spectrum is CRM, not VRM).
In Me-Ville, everything is anonymous and reputation/value-based. In the Global Village, its all about long-term relationships. I think this divide is interesting and sums up the differences in the approach taken by techies, like Alec Muffett and me versus the approach the fluffier, social people like Adriana Lukas and Doc Searls would like to take.
Who’s right? Well, normally I’d say I am, but I’m not sure I really know in this case. But recognition is the first step towards reconciliation.
ShmooCon News - ShmooCon 2008 Keynote - Edward W. Felten
ShmooCon and The Shmoo Group are pleased to announce that this year's keynote address will be given by Edward W. Felten.Edward W. Felten is a Professor of Computer Science and Public Affairs at Princeton University, and is the founding Director of Princeton's Center for Information Technology Policy. His research interests include computer security and privacy, especially relating to media and consumer products; and technology law and policy. He has published about eighty papers in the research literature, and two books. His research on topics such as web security, copyright and copy protection, and electronic voting has been covered extensively in the popular press. His weblog, at freedom-to-tinker.com, is widely read for its commentary on technology, law, and policy.More information on the rest of the speaker line-up coming real soon now.
He was the lead computer science expert witness for the Department of Justice in the Microsoft antitrust case, and he has testified in other important lawsuits. He has testified before the Senate Commerce Committee on digital television technology and regulation, and before the House Administration Committee on electronic voting. In 2004, Scientific American magazine named him to its list of fifty worldwide science and technology leaders.
ShmooCon News - Another Lead on Hotels
Rumor has it the Capital Hilton has some rooms.ShmooCon News - More Hotel News
Well folks...It looks like our room block is close to full. The hotel (not just our room block) is full for Friday night, but there are a few rooms remaining on Saturday. If you haven't made your room reservation yet, you might find yourself begging for floorspace from a friend. Or you could try some of these other local area hotels:
Kalorama Guest House
Washington Hilton
Omni Shoreham Hotel
Of course, we can't promise they have rooms either but at least it's a starting point.
Ben Laurie - Presence is a Privacy Problem
I don’t know why I’ve never written about this before. One thing that’s always bugged me about instant messaging is that I can’t choose who sees my presence and who doesn’t. As a result, I don’t advertise presence, as people who IM with me will know.
Why do I care? Mostly because I am being a purist. But the purist point is this: by my presence information I give away information that can be correlated across channels. To take Kim Cameron’s favourite example, if my alter ego LeatherBoy always comes online at the same time as me, someone who can view both alter egos can eventually make the correlation. There are other channels - for example if LeatherBoy is always online when I buy something at Amazon, then, again, one can start to entertain the notion that we are the same.
There are people I wouldn’t mind assisting in organising their time by advertising my presence to. And probably others to whom I’d like it to be fabricated. But I can’t do that. IM is broken.
I did toy with turning it on, but with the definition of idle turned up really high (like, after 100 minutes), but the problem there is you can time my actual idle time from my advertised time and likewise the time I come back online. Clients don’t (currently) offer the option of being somewhat random about when they start to advertise a status change.
At least, though, I can fix that problem by modifying the client code. The selective presence problem is less tractable: the protocols do not support it.
ShmooCon News - Hotel Info
Posting this again so it's readily available:The room block at the hotel is still open. Call in reservations can simply reference ShmooCon to get the discounted rate. Make your online reservations here.
Now go get some sleep!
ShmooCon News - So that took
about 15 minutes. Tickets are sold out for ShmooCon 2008. A big thanks to everyone! Keep watching this space for upcoming information about speakers and contests. The next few weeks are busy ones (for us anyway).See you in February!
(Oh and one more thing - don't write in asking about coupons for restricted tickets. They aren't available for general consumption.)
ShmooCon News - Last Round Ticket Sales
Don't have your shmoocon ticket yet? Lucky for you, our last round of ticket sales go live tomorrow, January 1st, 2008 at NOON EST.Happy New Year from the ShmooCon Crew and good luck!
Ben Laurie - Australian Doublespeak
Isn’t it amazing that politicians have so little respect for their electorate that they are quite willing to say things like this?
Telecommunications Minister Stephen Conroy says new measures are being put in place to provide greater protection to children from online pornography and violent websites.
“Labor makes no apologies to those that argue that any regulation of the internet is like going down the Chinese road,” he said.
“If people equate freedom of speech with watching child pornography, then the Rudd-Labor Government is going to disagree.”
I’m sure there’s no need to explain yet again why the Australian idea that they can filter the ‘net is doomed. But what does need some explaining, in my view, is why Conroy thinks he can get away with equating “protecting children from online pornography” and “watching child pornography”? Why have journalists become so passive that they will happily quote such nonsense without any inclination to do some actual analysis of the “news” they so mindlessly quote. It’s no wonder traditional media are in fear of the blogosphere.
Ben Laurie - Handling Private Data with Capabilities
A possibility I’ve been musing about that Caja enables is to give gadgets capabilities to sensitive (for example, personal) data which are opaque to the gadgets but nevertheless render appropriately when shown to the user.
This gives rise to some interesting, perhaps non-obvious consequences. One is that a sorted list of these opaque capabilities would itself have to be opaque, otherwise the gadget might be able to deduce things from the order. That is, the capabilities held in the sorted list would have to be unlinkable to the original capabilities (I think that’s the minimum requirement). This is because sort order reveals data - say the capabilities represented age or sexual preference and the gadget knows, for some other reason, what that is for one member of the list. It would then be able to deduce information about people above or below that person in the list.
Interestingly, you could allow the gadget to do arbitrary processing on the contents of the opaque capabilities, so long as it gave you (for example) a piece of code that could be confined only to do processing and no communication. Modulo wall-banging, Caja could make that happen. Although it might initially sound a bit pointless, this would allow the gadget to produce output that could be displayed to the user, despite the gadget itself not being allowed to know that output.
Note that because of covert channels, it should not be thought that this prevents the leakage of sensitive data - to do that, you would have to forbid any processing by the gadget of the secret data. But what this does do is prevent inadvertent leakage of data by (relatively) benign gadgets, whilst allowing them a great deal of flexibility in what they do with that data from the user’s point of view.
Ben Laurie - Spicey Chicken with Orange
This is inspired by a Ken Hom recipe for beef and orange, which I often cook to use up leftover roast beef.
Chicken breasts
Spring onion
Ginger
Dark soy sauce
Groundnut oil
Dried red chillis
Orange zest
Szechuan peppercorns
Rice wine
Sugar
Sesame oil
Thinly slice the chicken breasts (about 2-3 mm thick, across the grain). Marinade them in dark soy, finely chopped spring onions and slices of ginger (I use a lot of ginger, because I love it) for at least 30 minutes.
Heat some groundnut (or other) oil in a wok over a high heat until it is smoking. Throw in two lightly crushed dried red chillis and stirfry for a few seconds (this will produce smoke that makes everyone cough - this is normal), then add the chicken and stirfry until it is just cooked (should only take a minute or two, depending on quantity and how much heat you can bring to bear). Add finely sliced orange zest, crushed Szechuan peppercorns, more soy, a smidge of rice wine and a little sugar. Stir and fry for another couple of minutes. Take off the heat and stir in a little sesame oil.
Eat with plain boiled white rice and a simple vegetable (I did pak choi with soy last night).
Some notes: dried red chillis, despite being very, very small are really quite hot. Two of them to a pound or so of chicken gives noticeable (but not fire-hydrant-requiring) bite.
Szechuan pepper is not related to pepper at all (I believe it is some kind of ash, in fact) and I know of no substitute. It is vital to the flavour of this dish. For guidance, for a pound of chicken I’ll use about a teaspoon of Szechuan pepper, lightly crushed in a pestle and mortar.
Sesame oil is entirely optional, but I’m a big fan. I’d probably sometimes also add some more spring onion at the same time as the sesame oil, but I didn’t last night, so I am not specifying it. Spring onion that has been wilted by the heat of the dish alone is delicious, IMO.
The secret of tender chicken is to not overcook it, so you really need to stop stir-frying it and add the rest of the ingredients as soon as you can - even a little before all the chicken is thoroughly cooked. Because it is so thin, as soon as the outside looks done (i.e. has changed colour - it gets lighter when it cooks), it is done all the way through. If the chicken does not feel moist and delicate, you overdid it.
Ben Laurie - Is IdP Discovery The Next Big Thing?
I’ve been thinking. Even though us fans of user-centric identity like to think of it all being in the hands of individual users, it seems to me that in practice many users will delegate management of their identity data to a third party. They’ll do this for a variety of reasons, the main one being convenience, though the need to be always on may be a driver in the end, too.
So this leads to an interesting question: when I first arrive at a site, how does it know who I’ve chosen to be my IdP? When I turn up at Unicorns-R-Us, how do they know that they should go to Amazon to verify that I’m logged in and that I’m the same guy as shopped there last time?
This question is, of course, the question of IdP discovery, and although we’re not worrying about it much right now (at least in the user-centric world - I know Liberty has worried about it forever), I predict that we’ll be worrying about it a lot, Real Soon Now.
But why is it an issue? There seem to be all sorts of obvious options…
1. The OpenID approach: you (the user) give a URL to Unicorns-R-Us, and at that URL can be found further information about your identity. Clunky and weird for the average user.
2. Cookies. The first time you visit Unicorns-R-Us some miracle occurs that informs them I am an Amazon user and they set a cookie so they’ll always know in future. Two problems here, the first being that we still have that first encounter to solve and the second being that this works fine until you switch to my laptop and then you’re screwed.
3. Client-side component. This works well, and solves the first encounter problem, but still suffers from the issue of me switching to a machine without the component installed - or with it installed, but not yet initialised. Will I know how to initialise it, since that’s probably something I’d only do once a year or so? It can’t be too easy, or that’s clearly a security risk.
I’m starting to run out of ideas here, and so far none of them have worked really well. I suspect that in the end we’ll end up with the OpenID approach (”ask the user”) but with something more friendly than a URL and with a flow that often requires no effort on the part of the user. But its an interesting question that I don’t have a good answer to - and a good answer is key to a user-centric identity world.
I predict that figuring out standards and a good user experience around this problem will be one of the major pieces of the user-centric identity puzzle over the next couple of years.
Ben Laurie - Notification on Personal Data Breaches
The government waited nearly a month before revealing that they had lost personal data on 25 million UK citizens. Presumably they could have waited forever if they’d thought they’d get away with it.
If you agree that there ought to be a law obliging organisations to reveal such breaches, then the petition for you is right here.
Ken Caruso - CUWiN Homer Mesh Project
The CUWiN folks spent some time recently adding new equipment to the Homer mesh network. My company Metrix has provided them with all the gear for this project to provide the Village of Homer with a low cost tubes. Tags:community wireless cuwin mesh metrix seattlewiress wirelesscommunity wireless, cuwin, mesh, metrix, seattlewiress, [...]Ken Caruso - Shmoocon Labs 2008
Recently I have been getting all the stuff for Shmoocon Labs off the ground. In case you don’t know Shmoocon Labs is an event held one day prior to Shmoocon. The basic idea is as follows. Get 30 or so geeks, a handful of vendors with cool gear and spend a day hammering out the [...]ShmooCon News - CFP Closed
The Call for Papers for ShmooCon 08 is now closed. Thanks to everyone who submitted. Final notifications will be made by January 10th. Check out our speakers page as we update it along the way.In other news, the room block at the hotel is now open. Call in reservations can simply reference ShmooCon to get the discounted rate. Online reservations are also available. Rooms will go fast. We suggest reserving early and sharing with those you like best.
New information has also been posted regarding ShmooCon Labs, Hacker Arcade, and Hack-or-Halo.
ShmooCon News - Last Day for Paper Submission
The ShmooCon 08 CFP deadline is today. Our speaker selection committee will continue to review papers in earnest over the next few short weeks and final round speakers will be notified by Jan. 10.First round speakers have been posted online.
Ben Laurie - Caja and OpenSocial
An obvious place to use Caja is, of course, in OpenSocial. So, a bunch of us at Google have been experimenting with this use case and the first outcome is an update to the container sample which allows you to try running your gadget Caja-ised (gotta think of a better name for that). We even have instructions on how to Caja-ise your gadget.
We haven’t tried many gadgets yet, but the good news is the example gadgets worked with (almost[1]) no change. It seems clear that more complex gadgets are not likely to survive without at least some change but we don’t yet know how hard that’s going to be. Feedback, as always, welcome! And don’t forget to join the mailing list to discuss it.
[1] Right now, because Caja-ised code gets pushed into its own sandbox, you have to export any functions that need to be visible to the rest of the page (for example functions that get called when you click a button) - right now, you have to explicitly perform that export but we expect to be able to remove that requirement.
ShmooCon News - And they're outa here...
Tickets went quickly yet again - selling out in about 20 minutes. Those "I Love ShmooCon" tickets tend to linger just a little bit longer than the rest. To everyone who bought a ticket: THANK YOU.Next round of ticket sales is Jan 1st, 2008 at Noon, EST.
ShmooCon News - 2nd Round Ticket Sales
Go live tomorrow, December 1st, at NOON EST. You've been warned. :)Ben Laurie - Can HMRC and NAO Protect Their Own Data?
(Update: an ORG colleague correctly points out I should say “redacted” not “elided” - thanks, Louise!)
In the wake of the HMRC disaster (nicely summarised by Kim Cameron), the National Audit Office has published scans of correspondence relating to the lost data.
First of all, it’s notable that everyone concerned seems to be far more concerned about cost than about privacy. But an interesting question arises in relation to the redactions made to protect the “innocent”. Once more, NAO and HMRC have shown their lack of competence in these matters…
A few years ago it was a popular pastime to recover redacted data from such documents, using a variety of techniques, from the hilarious cut’n'paste attacks (where the redacted data had not been removed, merely covered over with black graphics) to the much more interesting typography related attacks. The way these work is by working backwards from the way that computers typeset. For each font, there are lookup tables that show exactly how wide each character is, and also modifications for particular pairs of characters (for example, “fe” often has less of a gap between the characters than would be indicated by the widths of the two letters alone). This means that if you can accurately measure the width of some text it is possible to deduce which characters must have made up the text (and often what order those characters must appear in). Obviously this isn’t guaranteed to give a single result, but often gives a very small number of possibilities, which can then be further reduced by other evidence (such as grammar or spelling).
It seems HMRC and NAO are entirely ignorant of these attacks, since they have left themselves wide open to them. For example, on page 5 of the PDF, take the first line “From: redacted (Benefits and Credits)”. We can easily measure the gap between “:” and “(”, which must span a space, one or more words (presumably names) and another space. From this measurement we can probably make a good shortlist of possible names.
Even more promising is line 3, “cc: redacted@…”. In this case the space between the : and the @ must be filled by characters that make a legal email address and contain no spaces. Another target is the second line of the letter itself “redacted has passed this over to me for my views”. Here we can measure the gap between the left hand margin and the first character of “has” - and fit into that space a capital letter and some other letters, no spaces. Should be pretty easy to recover that name.
And so on.
This clearly demonstrates that those who are entrusted with our data have absolutely no idea of the threats it faces, nor the countermeasures one should take to avoid those threats.
Ben Laurie - Happy Birthday: ORG Is Two!
It seems only yesterday that I sat with a group of starry-eyed activists and had the first board meeting of the nascent Open Rights Group. But I am reliably informed it was two whole years ago. In that time we’ve defied dead musicians, monitored elections and beaten up Auntie. Read all about it.
And once you have, GIVE US YOUR MONEY. ORG relies on the support of people like you - and not nearly enough of you are putting your hands in your pockets. We’re not asking for much, but without it, we can’t go on fighting your fight.