HTML5 Update

Yes, we know about some of the good stuff in html5 already but a lot of new specs have been added to the html5 family in the last year that will try to make the following available to web applications, i.e.,

• TTS
• Speech Recognition
• Recording
• Microphone Access
• Camera Access
• WebGL
• Positional Audio, still very early, don't know if will be based on OpenAL, OpenSL ES or something else
• File & Device API
• and more...

Android can be Dumb Too

Here's something you would expect if you were coding on the BlackBerry platform but this is most definitely on Android. Android doesn't implement roaming itself.

What? Yes, it's true. If you enable roaming in global system settings, it doesn't actually stick unless each and every single application you use honors the flag. Furthermore, if you don't implement it, Google states that it's the application developer's problem if your users complain about very large data bills.

So to implement it in every application, you need to check ConnectivityManager to see if you're allowed to use the network, e.g.,

final ConnectivityManager cm = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);

// TODO check the connection to see if it's allowed

You also need to check for the CONNECTIVITY_ACTION intent in case this changes later on. Honestly, this should just be blocked by the system. They're afraid someone won't be able to get to emergency services. It should just support an emergency level flag for network connections instead of getting all developers to implement this in their apps.

iPhone dev on Windows

As of VirtualBox 3.2.2 it is now possible to do iPhone dev on your Windows box. VirtualBox 3.2.0 introduced support for OS X as a guest OS, however there was a bug that broke iPhone/iPod Touch usb support on Windows hosts, this has been fixed in the 3.2.2 release.

So without further ado, here are the (amazingly simple) instruction for installing OS X 10.6.3 as a guest OS in VirtualBox on Windows.

1) Create a new virtual machine, the guest OS is Mac OS and for the version I used Mac OSX Server, not server 64-bit (I haven't tried 64-bit yet), disable EFI.
2) Download EmpireEfi and choose the BootCD.iso as your CD image.
3) Edit the VM's xml file and add the following to the section:

<ExtraDataItem name="VBoxInternal2/SmcDeviceKey" value="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"/>

4) Boot from the CD and follow the EmpireEfi instructions. You can install OS X using a retail DVD.
5) Unlike VirtualBox 3.2.0, the built-in EFI bios will not boot OS X, so keep using the EmpireEfi boot cd.

The Beauty of Google Chrome

Google Chrome is really an amazing application. A lot has been said about its performance and how Opera 10.5 is slightly faster in terms of rendering and JavaScript performance. However, Opera doesn't implement any of the sandboxing techniques that Chrome does, if it did, it would suffer a significant performance penalty. This is a look at Google Chrome on Windows.

What exactly does make Chrome so special? It's the fact that it uses recommended practices for Windows security. It's funny reading some of the archived documentation on MSDN. The documentation uses examples on how a future release of Internet Explorer or Outlook , carefully disclaiming that current releases do not leverage these security features, could use such feature to provide additional protection to users.

Needless to say, Internet Explorer (IE) and Outlook still do not implement these recommendations but Chrome does. It implements and leverages the following technologies from Windows:

1. Multi-process architecture

Yes, IE 8 has this also but their implementation is very different from the one found in Chrome. In both browsers, each tab represents a distinct process. On Windows Vista and higher, both mark the process as a low integrity level, more on this later. This is pretty much where the similarities' end.

In IE, the browser leverages the fact that each thread in Windows can have a message pump and have user object likes windows, buttons, etc. That means that each child process is managing the user interface of the tab directly. It also means that this child process, its threads and its resources live in the same security context that you do. The only difference however is that most risks are mitigated by marking the process as a low integrity one. This means however that squatter and shatter attacks can still be performed on other windows, just as long as those processes are also low integrity ones. All this to say that child processes render content to your screen.

In Chrome, child processes are also renderers but they do not actually manage anything on screen. They're renderers and these processes do not have a message pump that is coming from Windows' user interface layer. Instead, their message pump is a custom one that is listening on a named pipe in Windows (a socketpair() on OSX and Linux). They listen for requests, render data and send back the information to the broker process which is actually the chrome of Chrome.

In other words, they render everything to an off screen surface that never interacts with your screen. Even if it did, we'll see later that it wouldn't matter anyway.

That means when you click on something, a message from the broker process, Chrome's chrome, is sent to one of the renderers, once it's done processing the message, the renderer communicates back the result to the broker for on screen rendering. We can see how such communication would be expensive and how it would slow down Chrome. Making Chrome's performance, and Windows' implementation of named pipes, even more impressive to witness.

It's also important to note that the lifetime of a renderer process in Chrome can also be very short. If you navigate to something like "bank.com" to "robbers.com" using the same tab, Chrome has killed the renderer that was handling "bank.com" and spawned a new one to handle "robbers.com" even if you did not switch tabs. Not only does this make it impossible to leak any information from the first renderer to the new one, it's also a very effective way of doing garbage collection. All resources, including leaks, that were used by the now defunct renderer are reclaimed automatically by the kernel.

2. Restricted Tokens

Windows NT has token based security. Most objects, i.e., files, sockets, pipes, etc., in Windows are securable, if not in the beginning, the capabilities have been iteratively added in subsequent versions.

Chrome sets up a token for its child processes that translate to "deny access to everything token". This means child processes cannot acquire any resources that were not implicitly inherited from the broker. Even the named pipe that is used for communication with the broker cannot be opened directly by the child, it must be inherited.

3. Use of Windows job objects

Windows 2000 introduced support for jobs. Jobs in Windows have 2 distinct responsibilities:

• They include the ability to act on a group of processes atomically
• They allow additional security restrictions to be placed on this group of processes

The second one is of interest here. I'm not saying Chrome doesn't use the first, I'm saying it's of no importance to our stroll on its implementation of security.

Windows doesn't allow security to be set on various API it inherited from OS/2 and 16-bit Windows. This includes manipulating any User or GDI objects , this is what allows for things like shatter attacks, capturing keystrokes and all kinds of bad things. It's also what makes the desktop experience possible, so windows, copy & paste, etc.

It does so because introducing new interfaces that would allow for fine grained security and deprecating the old ones would pretty much deprecate every Windows application out there, including Microsoft's. It also wouldn't make for the same end user experience. A lot of the mechanics that users' take for granted today on Windows, OSX, etc., just wouldn't be possible or very easy to implement.

Microsoft, in the earlier days of Windows, also decided not to do this for another reason: performance. We can imagine that requiring to check the security permission of every single window object when broadcasting a message would be very expensive for computer's in service 10-15 years ago when a simple logon session routinely has hundreds of windows. Don't forget, there are a lot of hidden windows on your desktop.

However, instead of adding new functions with additional parameters for security, you can set the security and continue to use the same function. This is what Microsoft did with the job object. Specifying the job object allows to set other limits on these child processes that normally would have free reign, allowing you to forbid the following:

• Access to the clipboard
• Creation of new processes
• Access to other windows
• Access to the window station object's global atom's table
• Access to virtual desktop objects, ability to switch between them
• Logoff, login
• Creating new User objects
• Change system parameters
• Prevent hook functions, like trapping every key message, from being set

So once the job restrictions are set, normal function calls that would otherwise go unchallenged by the operating system are now restricted.

4. Use of Windows virtual desktop objects

The initial release of Windows NT, 3.1, had support for virtual desktops. However, this is circa 1989 for release in 1991, virtual desktops on Windows NT were not implemented to allow usage that is more in line with our thinking of virtual desktops today. For example, there is no way to switch a window from one desktop to another.

Instead, virtual desktops in NT were designed to be a security mechanism. They are the boundary of communication for User objects. This means if you install a global keyboard hook, you can also do so on your own desktop. If you broadcast a message to all windows, you're sending a message to every window on your desktop.

They were introduced so that login would be secure, that is, when you log on to Windows NT, there are 3 desktops created. The default one, the logon one and the screen saver one.

The logon one is only active when you lock your workstation and you need to unlock it. This allows for secure login since processes in the default desktop cannot create a keyboard hook into the logon desktop.

The screen saver is used to run the screen saver in its own sandbox. This means that a screensaver that is potentially malware would not be able to access your default desktop.

Of course, you still have the ability to create new windows on any desktop unless the proper steps are taken to secure them and this is indeed what Chrome does. Since its child processes don't have a user interface you can actually see, the child processes are nonetheless in a new desktop.

All these child processes also run in a job object that forbids them from accessing any of the virtual desktop functions. This means these processes can still interact with other low integrity processes but the only other processes these renderers can see are the one's found on Chrome's dedicated desktop for renderers. This is a step further than just marking the children as low integrity. The only possible squatter or shatter attacks that would be possible would be on other processes found in this desktop, problem is however for the would be attacker, is that these renderers don't actually have a user interface either.

5. Integrity level

The integrity level mechanism introduced in Vista allows for processes to be imbued with a level of trust. If a process wants to interact with a process of higher integrity, a UAC prompt is required to escalate the process. Also, low integrity processes do not have the ability to read any system objects or modify them

Chrome and Other Browser's Today

None of these mechanism are being leveraged by Firefox, Opera or Safari. Internet Explorer uses jobs and multi-processes but the sandbox is limited in scope compared to the one found in Chrome. Just food for thought on what browser you should be running to navigate the hostile web.

A final note, Microsoft has announced that it does not plan to support Internet Explorer 9 on anything less than Windows Vista SP2 stating only that "a modern browser requires a modern operating system". We're quick to point out that Chrome does indeed run on Windows XP. However, it is interesting to understand Windows XP's impact on Chrome.

It impacts Chrome in a few fundamental ways, the first one, is that, integrity levels were introduced in Vista, so it's not possible to mark child processes as low in Windows XP. This means these child processes have more privileges. However, due to other efforts realized to execute the renderer's under a proper sandbox, the scope is somewhat limited. The problem lies more in the ability to change system objects like registry keys. Registry key access is also governed by tokens but most users run as administrators under Windows XP.

More importantly however are the following:

1. Windows XP does not require NTFS. It obviously supports it but installation on FAT32 is also supported. This means that the restricted token assigned to the child processes under such a file system will not forbid a compromised renderer from opening new files. Funnily enough, an attacker would need to deduce the path to any file he wishes to open however since listing of files would be prevented by the restricted token. Unfortunately, it's more than easy enough to deduce the path to important Windows' system files.
2. Sockets are not securable objects. That's right, before the introduction of Vista, sockets are not governed by any token or any kind of security at all. That means a compromised renderer could create any number of new network connections. This could be used to download malicious code and then inject them in the files that were opened in the step above.

Ultimately, even on Windows XP, the sandbox setup by Chrome is nonetheless very impressive. Users should still be wary of that particular version of Windows compared to what is offered by Vista and above.

Chrome and Virtual Desktop Manager

Now that I have my new laptop, I decided it was time to find a better virtual desktop manager. I had been using the creatively named Virtual Desktop Manager with mostly good experiences, but a few quirks. One of the more annoying ones is artifacts that occur sometimes, but are persistent, when switching from a desktop with Chrome to one without. After a few days of uptime, I would find ghostly outlines of Chrome windows on all my desktops, and sometimes even orphaned status messages of the variety you get in the bottom left of the browser window when you mouse over a link or are loading a page. Pretty annoying! The second quirk is a blank and non-responsive "Write (no subject)" window courtesy of Thunderbird when you compose an e-mail and switch desktops before sending it.

Anyway, all that has been resolved with the use of Dexpot, I heartily recommend it.

Two Finger Click and Scroll

One of the (many) things that Apple get right on their Macbooks is the touch pad, it is large and supports nice multi-touch gestures.

My new laptop, an Asus G73, features the nice large touch pad and supports multi-touch gestures, like pinch-zoom, but it misses the best two gestures - two-finger scroll and two-finger tap to right-click. Fortunately, there is a remedy to this deficiency: Two-Finger-Scroll. So now I get the Macbook quality touch pad experience with twice the cores, way better graphics and more than enough money left over for a fast ssd!

Java3D offscreen rendering and changing colours

I just ran into an irritating quirk (perhaps bug?) in Java3D. I'm using the offscreen rendering feature of Canvas3D to render a simple 3D scene to a PNG file. The requirement is simply to produce a PNG given certain input parameters, notably colour.

My first attempt was very straight-forward; create my scene, with the correct colours and render it to the PNG. Repeat as required. The last part, repeat as required, is problematic. Each time you create an offscreen Canvas3D you create an OpenGL PBuffer. My graphics card as 32 pbuffers so the 33rd time you render the scene, the program crashes.

A second attempt is obviously required. The requirement being to use only one Canvas3D object and thus only one scene graph and to change the colour of the scene before re-rendering it. First, some background, my objects are Boxes and to set their colour you have to set an appropriately configured Appearance. For example:

final Material material = new Material();
final Appearance appearance = new Appearance();
final Box cube = new Box(1, 1, 1, appearance);


material.setDiffuseColor(someColor);
appearance.setMaterial(material);

This simply creates a cube using the Box utility class and sets a color on it. Java3D will optimize the scene graph and part of that optimization assumes that the scene doesn't change, unless you explicitly state that it can. Changing the colour would be one of those things you have to state. There are plenty of forum topics about changing the colour of a Box and they usually suggest changing the Appearance object, like so:

final Box cube = new Box(1, 1, 1, Box.ENABLE_APPEARANCE_MODIFY, someAppearance);


[...] // Some time later
box.setAppearance(aDifferentAppearance);

The ENABLE_APPEARANCE_MODIFY flag simply tells Java3D to assume that the Appearance object associated with the Box can change. This should allow you to change the appearance at will. Except in offscreen rendering mode, this doesn't work. Not only does it not work, but any initial colour you set is ignored and you get a white Box. After much messing about, I found that ENABLE_APPEARANCE_MODIFY was the cause. The solution to this is to change the colour on the material directly and not simply set a new Apperance.

final Material material = new Material();
final Appearance appearance = new Appearance();
final Box cube = new Box(1, 1, 1, appearance);


material.setCapability(Material.ALLOW_COMPONENT_WRITE);
material.setDiffuseColor(someColor);
appearance.setMaterial(material);
[...] // Some time later
material.setDiffuseColor(aDifferentColor);

And there you have it, Boxes that change colour in an offscreen rendered scene.

Red Rings Again and for the Last Time

Once again, my Xbox 360 has been hit with the 3 Red Rings of Death error. Once again, I called Microsoft only to be told that it was out of warranty this time around and it would cost me $150 to repair it. After explaining my history, this was my 4th console after all, they graciously offered to repair it for free. The catch is that I had to get it to a UPS store myself which isn't anywhere near me.

Well, I got the console back again this last Monday and got 4 Red Rings this time. Called support again, they were willing to repair it but when they mentioned I would have to get it back to the UPS store, I decided enough is enough. The customer service representative explained that my preferred courier was indeed supported, i.e., the one that is just a few blocks away and the same one I received the latest damaged console from, but that the Xbox support system was randomly generating labels to even out the various couriers Microsoft uses. I politely asked for a label from another courier and was told there was nothing they could do.

So this will be the last time I have issues with Red Rings. The games, accessories, etc., are heading to EB Games and the console is headed to the garbage bin. Fool me once Microsoft... but I've had enough.

The Sanity of Google Chrome Frame

OK, so having had to support CSS in Internet Explorer 6, 7 and 8. This isn't so insane after all. Turns out, it's much less effort to fix IE with a free add-on, that doesn't even require administrator privileges, than it is to fix CSS to work in IE.

I now recommend using Google Chrome Frame over actually making stuff that works correctly in IE. This just shows you the sorry state the IE is in. Microsoft is working on fixing IE with 9 and beyond but it just won't help all those people who don't really know what a browser is. However, asking for a plugin, and one from Google no less, will reach all audiences.

So the people at Google weren't insane, they just felt it was less work to fix IE than to break sites to comply with IE's view of the web. What I didn't understand at the time however, is that you can't just show a page when your user reach your site telling them to install another browser because too many people don't know what a browser is really. Also, in a corporate environment, they probably can't install one either even if they do.

Moving on to Scala... Hopefully

Ah, Scala, I became infatuated with this language some time ago when I saw the following video presentation from fosdem 2009.

This language is such an evolutionary step over what was there before that's it really makes you think what's coming up in the future. By that, I mean what else will come from this field which was once thought to be done, where original research was basically considered to be all over.

So, why hopefully? Well, the problem with Scala, much like any new language, is tooling. The good news however is that Scala produces Java Bytecode instead of starting from scratch.

Meaning that's it's still a pain to use your favorite IDE, Netbeans in my case, with this language. However, leveraging the existing Java platform means that it doesn't suffer from things that would normally suffer any nascent language:

1. Uses the JVM, so performance is what you would expect. It's fast and works well.
2. Tons and tons of libraries because it can access any Java library out there.
3. Continuous integration servers and other tools that you would want to complete your development life cycle are all readily available since it's Java based
4. Mature application servers. Code produced from the compiler is Java Bytecode, hence any Java EE server, like Glassfish, will just work.

Unfortunately, for now, until the Netbeans support matures, I won't be using this. However, I would recommend developers still have a look at that video. It's hard to look at this video without being in total awe of what's going on.