The iPhone NDA Español | Deutsch | Français | Italiano | Português

So last night I pre-ordered a copy of Erica Sadun's "iPhone Developer's Cokbook" from Amazon. The expected ship date is sometime late in October, but I'll be surprised if that's even vaguely accurate considering the ongoing problems with the NDA. Developers are now resorting to paying each other US$1 so they can be a sub-contractor, and presumably have some sort of legal protection against Apple's legal team and the NDA, before sharing information about developing against the official iPhone SDK.

So I doubt Erica's publisher will let her release the book until the NDA is lifted, and she isn't alone in having that problem, there are no doubt a bunch of books, tutorials and other such things waiting in the wings, waiting for Apple to lift the NDA.

However it currently seems to be a case that it's not when the NDA is lifted, but if it's going to be lifted at all. In what is now being called the fourth age of software distribution, might yet more companies adopt this bullying approach? That's a faintly scary prospect for independent developers like me...

Border Gateway Protocol Español | Deutsch | Français | Italiano | Português

Close on the heels of the publicity surrounding cookie hijacking there is now another potentially much more serious problem, this time with the Border Gateway Protocol the core routing protocol underlying the Internet...

An interview with Damian Conway Español | Deutsch | Français | Italiano | Português

An interview with Damian by Terry Camerlengo

Cookie Hijacking Español | Deutsch | Français | Italiano | Português

Things are looking a bit grim on the security side. Close on the heels of the DNS cache poisoning flaw discovered by Dan Kaminsky last month, there is now a new bogie man, automated HTTPS cookie hijacking...


Time progression showing vulnerable DNS servers: Red dots represent unpatched servers, yellow dots patched servers with NAT problems, green dots are patched servers.
The problem has gotten a lot of attention with respect to unencrypted GMail sessions, in fact there is now a widely available automated tool which allows you to steal session cookies on HTTP and HTTPS sites that do not set the cookie secure flag.


Surf Jacking Gmail demonstration from Sandro Gauci on Vimeo
However the problems is more widespread than just GMail, although there are still problems even there, and potentially affects a much broader range of sites.

Since so many sites are likely vulnerable, the actual reporting process is probably going to fall on the shoulders of users. To check your sites under Firefox, go to the Privacy tab in the Preferences window, and click on "Show Cookies". For a given site, inspect the individual cookies, and if any have "Send For: Encrypted connections only", delete them. Then try to visit your site again. If it still allows you in, the site is insecure and your session can be stolen. You should report this to the site maintainer. - Mike Perry

Of course we can't all go hide in a darkened room and realistically, unless you're a high profile target, your chance of getting caught by this vulnerability is fairly low. However potentially at least, this is serious. You email, merchant account, banking and other personal information are potentially at risk. Right now it's not clear how widespread this problem actually is, so be careful out there...

Poor indexing? Español | Deutsch | Français | Italiano | Português

Nick Carr passes on James Evan's argument in a recent issue of Science that the chief advantage of print media is "poor indexing". How bizarre...

Ironically, my research suggests that one of the chief values of print library research is its poor indexing. Poor indexing—indexing by titles and authors, primarily within journals—likely had the unintended consequence of actually helping the integration of science and scholarship. - James Evans in the Britannica Blog

Paper Phishing Español | Deutsch | Français | Italiano | Português

So we're all used to identifying and avoiding phishing attempts via email, but what about when it happens on paper? Today I received an actual paper letter, purporting to be from one of my banks, advising me that they had contacted me some time ago and hadn't had a reply, and that the due to a change in the law they needed to update the information about my extra card holder.

The letter looked genuine and included a 'Extra Cardholder Information Form' and a prepaid envelope to provide the details, and a freephone number that I could alternatively call to provide them. It went on to advise me that if I still needed my extra cardholder I must provide the information within 28 days or they would remove the extra card from my account.

So it looked genuine, except it sort of didn't. My finely tuned spider sense was tingling, if this was an email it wouldn't have even made it past my spam filter.

Despite the fact the letter had my account number on it, and was sent to my address, I was suspicious. So I called the fraud division of the bank in question, they had no record on my account of sending out such a letter, and the freephone number didn't, as far as they knew, belong to them. I'd just been the (almost) victim of a paper-based phishing attack.

Both of us were surprised, this is the first example of a paper-based phishing attack that I, and perhaps more worryingly the bank, had come across. If you get a letter that doesn't look quite right from your bank and is asking for personal information that, as far as you know, they should already have, call your bank on a number you know is genuine to confirm that it was actually from them.

It looks like the bad guys just raised the stakes, and we're now playing a new game entirely. It also looks likely that there has been some sort of major compromise with this specific bank, there were too many details in the letter to have come from a retail source. So this is your warning, keep your guard up...

Interrupted Journeys Español | Deutsch | Français | Italiano | Português

For those of you puzzled by my early departure from OSCON a week ago, and my non-appearance at HTN IV this week, I'd like to announce the very unexpected early arrival of my son, Alexander Michael. Born late yesterday evening, just under two months premature, and weighing just over 4 lbs.


Both mother and baby are doing well...

OSCON: Wednesday Morning Keynote Español | Deutsch | Français | Italiano | Português

My jet lag caught up with me last night and I ended not making it to the Tuesday Night Extravaganza, although other people did and cruelly didn't blog Damian's talk for the rest of us that didn't. So I don't get to find anything more about "Temporally Quaquaversal Virtual Nanomachine Programming In Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces", which is a pity...


The keynote kicked off with Allison Randall and Edd Dumbill, talking about the history of Open Source and OSCON. This is the first OSCON without Nat at the helm, and while I've seen him around, it's pretty weird not to have the keynote kick off with "...and here's your conference chair, Nat Torkington".

Update: Looks like I'll see you all next year. While I was in the keynote I got a phone call and I'm now heading back into the UK somewhat earlier than planned.

Update: More than one interrupted journey...

Perl on Google App Engine Español | Deutsch | Français | Italiano | Português

I woke up this morning to some of the best news I've heard in a while, it looks like there is some progress with putting Perl onto Google App Engine.

More from Brad Fitzpatrick. If you'd like to discuss this or help out, join the perl-appengine mailing list, and submit code to the appengine-perl project on Google Code. For more information see the Perl-on-AppEngine FAQ.

Maybe I won't have to learn Python after all...

OSCON: Practical Erlang Programming Español | Deutsch | Français | Italiano | Português

This afternoon I'm sitting in "Practical Erlang Programming" given by Francesco Cesarini. Erlang has been around for almost twenty years, and is a niche language. However we're increasingly starting to hear more about it due to the growth in the number of multi-core machines. So I figured I so go and find out what all the fuss was about...


Update: I think Francesco has really overestimated the capacity of the wireless network, he's just told ninety people to download the source bundle and install Erlang.

Update: Okay, we're kicking off with data types; integers, floats, atoms are the simple types. Then we have tuples and lists. Interestingly variables in Erlang are single assignment, an values of variables can not be changed once it has been bound. Puzzled, variables are not very variable at that point?

1> A = 123.
123
2> A.
123
3> A = 124.
** exception error no match of right hand
4> f().
ok
5> A = 124.
124

Update: Pattern matching is used for assigning vales to variables, controlling the executing flow of programs and extracting values.

Update: Moving onto to function calls, this looks, well. Odd.

area( {square, Side} )      ->
  Side * Side ;
area( {circle, Radius } )   ->
  3.14 * Radius * Radius;
area( {triangle, A, B, C} ) ->
  S = ( A + B + C )/2,
  math:sqrt(S*(S-A)*(S-B)*(S-C));
area( Other ) ->
  {error, invalid_object}.

Function have clauses separated by ';'. Erlang programs consist of a collection of modules that contain functions that call each other. Function and modules names must be atoms.

factorial(0) -> 
  1;
factorial(N) ->
  N * factorial(N-1).

Variables are local to functions and allocated and deallocated automatically.

Update: Modules are stored in files with the .erl suffix, module and file names must be the same. Modules are names with the -module(Name). directive.

-module(demo).
-export([double/1]).

% Exporting the function double with arity 1

double(X) ->
  times(X, 2).

times( X, N ) ->
  X * N.

compiling this from the command line

1> cd("/Users/aa/").
2> c(demo).
{ok,demo}
3> demo:double(10).
20
4> demo:times(1,2)
**exception error: undefined function demo:times

Update: We've now looked at the basics, we're moving on to sequential Erlang; Conditionals, guards and recursion.

case lists:members(foo, List) of
  true -> ok;
  false -> {error, unknown}
end

In a conditional one branch must always succeed, you can put the '_' or an unbound variable in the last clause to ensure this happens.

if
  X < 1 -> smaller;
  X > 1 -> greater ;
  X == 1 -> equal
end

Again, one branch must always succeed, by using true as the last guard you ensure that the last clause will always succeed should previous ones evaluate to false, see it as an 'else' clause. So we can have,

factorial(N) when N > 0 ->
   N * factorial( N - 1 );
factorial(0) -> 
   1.

instead of having this,

factorial(0) -> 
  1;
factorial(N) ->
  N * factorial(N-1).

Of these two the top one is the faster one, but you really shouldn't really worry about that when using Erlang, apparently...

All variables in guards have to be bound. If all guards have to succeed, use ',' to seperate them, if one has to succeed, use ';' to separate them. Guards have to be free of side effects.

Update: On to recursion,

average(X) -> sum(X) / len (X).

sum([H|T) -> H + sum(T);
sum([]) -> 0.

len([_|T]) -> 1 + len(T);
len([]) -> 0.

Note the pattern of recursion is the same in both cases. Taking a list and evaluating an element is a very common pattern...

Update: Now onto Build In Functions (BIFs)...

date()
time()
length(List)
size(Tuple)
atom_to_list(Atom)
list_to_tuple(List)
integer_to_list(234)
tuple_to_list(Tuple)

BIFs are by convention regarded as being in the erlang module. There are BIFs for process and port handling, object access and examination, meta programming, type conversion, etc.

Update: We're running through all the possible run time errors.

Update: We're breaking (late!) for coffee...

Update: ...and we're back, and walking through some examples, and onwards to concurrent Erlang.

Pid2 = spawn(Mod, Func, Args)

Before the spawn code is executed by Pid1, afterwards a new process Pid2 is created. The identified Pid2 is only known to Pid1. A process terminates abnormally when run-time error occurs, and normally when there is no more code to execute. Processes do not share data, and the only way to do so is using message passing. Sending a message will never fail, messages sent to non existing processes are thrown away. Received messages are stored in a process mailbox, and will receive them inside a receive clause,

recieve
  {resetn, Board } -> reset(Board);
  {shut_down, Board{ -> {error, unknown_msg}
end

Unlike a case block, receive suspends the process until a message which matches a case is received. Message passing is asynchronous, one of the things you look for in stress testing Erlang systems is running out of memory because of full mailboxes.

Update: We're getting into a static versus dynamic typing argument, the bizarreness is that even the Francesco seems to think that static typing is a good thing. Why is that? I'm really surprised, after all I'd argue that there are a bunch of reasons to use loosely typed languages in preference to statically typed ones.

Update: It's also interesting that some people in the audience here aren't getting the "let it crash" mantra coming from Francesco. In a highly concurrent language where everything is a process, letting a process crash is just how you handle errors. A process crash is essentially the same as throwing an exception.

Update: I'm starting to loose the thread of the talk now. Pity, Francesco has just got to the interesting bit. It's been a long day...

Update: ...and we're done. Chris was also blogging the tutorial so head over to his post for more coverage.