Syntactic sugar in s-expression languages (by alaric)

S-expression based languages (eg, Lisps, and by a broader definition of s-expression, things like Prolog) use a single regular syntax to represent the parse tree of code, rather than having parsing rules for each syntactic construct in the language. Read more »

Paul Graham (by alaric)

I like this guy's thinking on programming language design. It aligns pretty closely with my own ideas, and has some good ideas on syntax that I might borrow for CHROME...

And the way he implemented Viaweb is pretty similar to how I might have.

I think I'm more a fan of object orientation than he is, but this might just be a matter of terminology. I'm more of a fan of generic functions and Haskell-style classes than Java's OO.

MPLS (by alaric)

One technology I'd really quite like to play with is Multiprotocol Label Switching.

It's a network protocol, but one that doesn't entirely fit right in with the standard ISO model stack; it's a low-level packet switching protocol like IP, but it doesn't have a transport layer (TCP, etc) on top of it. It's just used to tunnel other protocols like IP and Ethernet over. Read more »

Social engineering (by alaric)

Bruce Schneier's blog as an article on a recent diamon heist carried out purely through social engineering. No high-tech descending on wires through skylights, gymnastic climbing through nets of laser beams, or reprogramming advanced electronic locks. Nope, the perpetrator just earnt the trust of the staff by appearing to be a nice harmless guy.

No amount of snazzy technology can prevent this kind of thing. Sure, you can make it harder in some ways, but people will still be the weakest link.

My suggested solution to this kind of crime is to make it everybody's civic duty to test security systems. Teach social engineering at school. If somebody is caught in an attempted non-violent non-property-damaging security breach attempt, congratulate them. If they manage to pull one off and get away with it but then fail to report the fact, throw 'em in jail - but if they DO report it and turn the goods back in, they get congratulated and a reward from the victim's insurance company.

Sure, this makes an actual malicious robbery slightly less risky (as long as you don't damage anything or anyone during the attempt, which is clearly against the rules of a good-natured security probe), since if you get caught in the act you can say it was just for fun and you'd have handed in the winnings if you'd not been caught, but actual successful robberies at that level are rare. And with a segment of the population worrying at any possible security hole in search of a finder's bounty, there'll be less security holes to exploit, and the staff will be a lot less trusting of nice folks...

Fuzz testing (by alaric)

Speaking of unearthing bugs, I'm surprised I've not found any mention of anyone fuzz testing NetBSD syscalls. There's a crashme tool which, despite the one-line summary doesn't actually call syscalls explicitly (although it may stumble across them at random) - it just executes arbitrary sequences of random numbers as code, in order to make sure all the CPU trap handlers work correctly...

So I may throw together a tool to do that for syscalls. Needless to say, it ought to be run as an isolated user (so it can only trash its own files), maybe in a chroot, and ideally on a machine without network access (for it could, in theory, open a network socket and do something unneighbourly :-).

This would be a good test of the higher-level inter-process isolation facilities in the OS kernel - namely, it'd help to find security holes such as local denial of service attacks against the kernel!

Also, another fun idea might be a fuzz tester for Xen hypercalls...