I'm interested in this as well. I'd love some technical details about how they're going to do the DRM stuff with just HTML5 audio. Does anyone have ideas?
I can guess they'd so something like a unique URL that expires quickly and checks the user agent/headers/other stuff. Like all of this kind of stuff, it won't be bulletproof, but it'll be good enough. I'm sure I'm missing some other option that's better, though.
There's no DRM with the current Flash iteration either. They use blowfish to obfuscate the audio URLs in the XML playlists, but the audio files themselves are standard unencrypted AAC/MP3 downloaded over HTTP.
The blowfish keys are easily grabbed after an update, it is off course a cat and mouse game, but overall pianobar and other stand-alone clients seem to be doing fairly well at keeping up.
I don't listen to music using the flash interface anymore, the biggest problem is that after just an hour or two of listening the flash application is using a HUGE amount of memory and is hogging one of my cores at 90%. Flash on Mac OS X was never anything to write home about ...
How come? Not being snarky, but I've been impressed with the current video tag support and how well it works. I'd assume the audio support works fairly well also.
Video is simpler: you normally play one video at a time, for long time periods. Audio tends to be used to play short clips simultaneously, and if the browser drops some or delays them, it ruins the effect.
I don't think they're doing that. They mention they've replaced the frontend - which makes a lot of sense, considering they want to turn it into a social media website - but makes no notes of actually dropping Flash. Plus there's no iPad compatibility mention, so... I'm guessing they still use Flash for playback.
Even better as Pandora was using Flash via OpenLaszlo (translation: making flash even slower via another layer of indirection). Now to convince my company that Flash+OpenLaszlo is not the future...