Daily Archives: January 4, 2011

Electronics, Rockbox

Rockbox seen on iPod Classic

6 Comments

Rockbox tiny

After a very long time of work, a very very long time since these devices were introduced on the mp3 player market, the hard working guys from freemyipod.org have produced something on yet another device. This is the same group that previously was called linux4nano and worked so long and fiercely to get code running on the 2nd generation iPod Nano and the 4th generation iPod Nano.

At the end of December 2010, Michael “TheSeven” Sparmann announced that he was running custom code including music playback on the iPod Classic. The (sometimes) so called 6th generation.

Robert Menes spiced up the story today by showing us a live picture of a Classic device that now actually is running Rockbox:

Rockbox on the iPod Classic

Awesome work Michael, truly impressive. I hope a lot of Classic owners soon will be able to try out Rockbox for real. Rockbox is said to not yet be very stable or functional, so there’s a lot of room for more hackers and developers to join in and help us improve!

Network, Web

WebSockets now: handshake and masking

In August 2010 I blogged about the WebSockets state at the time. In some aspects nothing has changed, and in some other aspects a lot has changed. There’s still no WebSockets specification that approaches consensus (remember the 4 weeks plan from July?).

Handshaking this or that way

We’ve been reading an endless debate through the last couple of months on how the handshake should be made and how to avoid that stupid intermediaries might get tricked by HTTP-looking websocket traffic. In the midst of that storm, a team of people posted the paper Transparent Proxies: Threat or Menace? which argued that HTTP+Upgrade would be insecure and that CONNECT should be used (Abarth’s early draft of the CONNECT handshake).

CONNECT to the server is not kosher HTTP and is not being appreciated by several people – CONNECT is meant to get sent to proxies and proxies are explicitly setup to a client.

The idea to use a separate and dedicated port is of course brought up every now and then but is mostly not considered. Most people seem to want this protocol to go over the “web” ports 80 and 443 and thus to be able to share the proxy environment used for HTTP.

Currently it seems as if we’re back to a HTTP+Upgrade handshake.

Masking the traffic

A lot of people also questioned the very binary outcome of the Transparet Proxies report mentioned above, and later on it seems the consensus that by “masking” WebSocket traffic it should be possible to avoid the risk that stupid intermediaries misinterpret the traffic as HTTP. The masking is currently being discussed to be XOR with a frame-specific key, so that a typical stream will change key multiple times but is still easy for a WebSocket-aware tool (say Wireshark and similar) to “demask” on purpose.

The last few weeks have been spent on discussing how the masking is done, if it is to become optional and if the masking should include the framing or not.

This is an open process

I’m not sure I’ve stressed this properly before: IETF is an open organization. Anyone can join in and share their views and opinions, but of course you need to argue technical merits.