The end to end argument

Scott Brim posted today on the IETF mailing-list one of the best defense of the end to end argument:

> On page 9, you state, based on a citation from RFC 4924:
> “We believe that providing end-to-end transparency […]
> is key to the success of the Internet.” I think this
> statement needs elaboration. End-to-end transparency
> is not a reason for the success of the Internet.

I invoke Feynman and the “philosophy of ignorance”. The reason you want e2e transparency is because you do not know what it might enable, and we want that. We _want_ to have uncertainty about what the future of the Internet is. We do not know what advantages or restrictions our decisions will bring in the future. The richness of the Internet experience has come about because we have given end users the capability to develop new ways of using it, and somehow managed to have got out of the way, so far.

Feynman said (among other things — search for it):

Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our responsibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that will stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, proclaiming “This is the answer, my friends; man is saved!” we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination. It has been done so many times before.

I am a long time advocate of the end to end argument and I wrote and talked about it in the past, so many thanks Scott for this.

Running code from strangers

Why anybody would download and run a binary program from a perfect stranger? I was looking at Apache logs to see if somebody was downloading a jar file I uploaded yesterday, when suddenly this question hit me. I did not release the code source because of lack of time to clean it and package it, so the potential users can not check the code source to verify that my program is not a Trojan horse but anyway source code or not, nobody will do a code review. So what can a user do to check that a program is really doing what its author says?

The program is in Java, so the solution is to run it under a security manager. This is really easy – just pass “-Djava.security.manager” to the JVM and any access to a security sensitive resource will throw an exception. Because this is a verification done by the JVM, there is no possibility for the program to bypass this. When the program runs without security manager, I just display a warning message like this:

You should not run random Java programs downloaded from the Internet without security manager.
Use the --help-security option to know how to do this.

Note that running the program under a security manager only one or two times to check that it is not a Trojan horse is not better than doing nothing; if I wanted to do something bad in my program, I would be sure to not do it when a security manager is installed, to not be detected.

Then comes the tedious task of writing a policy file to authorize the program to access the resources it is supposed to access and no more than this. One way of doing this is to add the “-Djava.security.debug=access” to the JVM command line and to add (or not) to the policy file a permission each time an access denied is found. The problem is that one needs to run absolutely all the options in the program to be sure to trigger all the security accesses, which is not very practical. The solution I chose for my program is to add an option that generates the policy file that is needed to run the program with the specific parameters under the security manager. Here’s an example:

$ java -Djava.security.manager -jar id2kindle.jar --generate-policy draft-ietf-behave-turn-uri-01.txt
grant {
  permission java.io.FilePermission "draft-ietf-behave-turn-uri-01.txt", "read";
  permission java.io.FilePermission "draft-ietf-behave-turn-uri-01.zip", "write";
};

The standard output can be redirected to the policy file, which is then used to run the program:

$ java -Djava.security.manager -jar id2kindle.jar --generate-policy draft-ietf-behave-turn-uri-01.txt >id2kindle.policy
$ cat id2kindle.policy
$ java -Djava.security.manager -Djava.security.policy=id2kindle.policy -jar id2kindle.jar draft-ietf-behave-turn-uri-01.txt

As long as the content of the policy file is verified before running the program, nothing bad can happen. Well, excepted that most people will run it at least one time without security manager and one time is all that is needed to do bad things.

Internet-Drafts for Kindle (2)

Yesterday I explained about my efforts to convert Internet-Drafts to a format that is usable on the Amazon Kindle. The solution described is certainly fine for the long-term, but does not help for the IETF meeting in 10 days. So for the short-term, I developed another Java program that takes an Internet-Draft or an RFC in text form and convert it to a series of images that can be displayed on a Kindle. All the nice features of the Kindle like reflow, dictionary, TOC, links, bookmarks, annotations, etc…, do not work with this, but that’s better than printing – and carrying around – 500+ pages. The program is available here:

http://ietf.implementers.org/id2kindle.jar

And can be used like this:

java -jar id2kindle.jar rfc3261.txt rfc3261.zip

The .zip file must be installed directly in a directory named /pictures on the Kindle 2. On the Kindle 1, the file must be unzipped in the /pictures directory.

On the Home menu of the Kindle use Alt-Z to rescan the flash memory and the new document should be selectable. Press J to switch the full page mode.

Formatting Internet-Drafts for the Amazon Kindle

The 74th IETF meeting is coming fast and it is time to start reading the latest version of all the Internet-Drafts relevant to the sessions one plan to attend. I counted 70 documents in my case, and that’s a lot of reading. Printing all this documents is bad for the environment but it is so far the easier way to manage this task especially because it is easy to annotate them directly with a pen. Reading on a laptop is not as convenient and does not make annotations easy.

I was thinking since few IETF meetings that my Kindle would be ideal for this task. It is small enough to be easily carried around, does not need to be recharged as often as a laptop, and permits to annotate documents. Unfortunately the text formatting of an Internet-Draft does not look very good on a Kindle, as it is optimized for text console with 80 columns.

So I wrote a converter that take in input a RFC 2629-formatted Internet-Draft and convert it to a .mobi document that displays nicely on a Kindle. I would have been happy to write an XSLT script for this task but unfortunately the Kindle cannot display correctly tables or some special formatting needed by IETF documents, so I used Java to generate the tables as images. The code is not very smart yet, but I was able to convert my 3 current I-Ds to .mobi files and they can be downloaded here:

http://ietf.implementers.org/

This will not solve the problem of reading all this drafts soon because very few authors upload the RFC 2629 version of their draft to the IETF website, but I hope that this will encourage people to start doing it.

Long distance flight

Everybody who ever had to take a long distance flight knows this sensation. As soon as the door is closed on the taxi taking you to the airport, all your preoccupations disappear and you fell instantaneously relaxed because there is nothing more that you can do. You spent the last hours frenetically trying to put everything in order, sorting important emails, preparing the baggages, calling the credit card company. After the door closed, the two only things you need to keep an eye on is your passport and your credit card – everything can be fixed as long as you still have these.

Well, resigning is just like this. You did your best to leave things in a good shape, but you no longer have access to the servers, or the code or the company’s emails, so there is nothing more that you can do. Then you feel this deep serenity where your mind is freed of all preoccupations – you know it will not last, but you appreciate very minute of it.

And there is another parallel that I can draw between resigning and long distance flights: Because I woke up each morning between 2:00am and 5:00am for so many years, I now have to recover from work-induced jetlag.

Bluetooth Stereo Headphones

I bought this Bluetooth Stereo Headphones at Fry’s three weeks ago, and finally manage to have them working with my Treo 650. I use Pocket Tunes (which is now free with the Treo 680) to play music from my ogg-encoded collection (stored on SD cards), but the headphones cannot directly work because the Treo 650 does not support the Bluetooth profile for stereo. The customer support for Pocket Tunes directed me to Softick Audio Gateway, a software that can redirect the audio to the Bluetooth headphones.
The buttons on the headset can be used to pause, skip and change the volume without having to touch the Treo 650.
The headphones can also be used as a phone headset with the disconnectable microphone. My only complaints would be that a smaller, integrated, microphone would have been better, and could have been used to implement noise reduction.
The sound is good, the battery lasts for more than 6 hours and can be recharged on a USB port, which means one less charger to carry around. I like this headphones very much as I no longer need to use the Palm Stereo Headset, excepted on-board a plane where I believe it is still forbidden to use Bluetooth.

@Syntax

I like programming in Java because it is a strongly typed language, i.e some classes of programming errors are discovered at compile time instead of at run time. The generics feature introduced in Java 1.5 is a great improvement that add another class of errors that can be discovered at compile time but at the same time some additions to the Java languages introduced new potential programming errors that cannot be easily detected at compile time.

The oldest feature with this problem was I think SQL. The SQL requests are stored in String objects and a syntax error can be detected only when the program itself runs – at best it can be detected when the program starts but in the worst case, e.g. if a SQL request is no used very often, it could be discovered too late. Sure it is possible to write unit tests to detect the error, but this a little bit overkill just to verify that the syntax is correct. Other examples of String objects containing structured text are used in MessageFormat, Pattern (regex), Formatter, etc…
So I wrote this small java annotation named Syntax. The idea is to annotate a String containing structured text with the type of syntax used. At compile time, it is then easy to check that the content of the String is valid. Here is the definition of the annotation:

public enum Language { REGEX }

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.SOURCE)
public @interface Syntax {
  public Language value();
  }

An annotation can then be added to a String constant:

@Syntax(REGEX)
private static final String MY_PATTERN = "[abc";

It is then simple to write an annotation processor that retrieve the value of the String and use Pattern.compile to check the syntax. The implementation for Pattern, MessageFormat, DateFormat and Formatter is only 72 lines. Adding SQL is a little bit more tricky, as there is nothing in the JVM to verify the SQL syntax. A simple solution is to use JavaCC that have free grammars for SQL and other languages.

The main limitation is that this annotation can be used only on a String constant, so the code needs to be slightly rewritten to take advantage of this technique.