This one isn't really security related, except that we security people often want to get rid of old stuff because it's sometimes easier to disable it than to make it really robust. If only a few people use it, good attack surface reduction practices tell us that it should be off by default, maybe an optional install. This sometimes causes user astonishment and even dismay. Someone commented back to me about some issues along these lines they were having with Office 2003 SP3, and I'll post about that soon.

So here's what happened – I have a lot of music, and all my CD's are ripped to disc using lossless format. It takes up close to 100 GB, and these days, that amount of storage is only about 1% of the cost of the CD's that I bought. Zune 1.0 doesn't understand WMA lossless, and so it converts to WMA at a bit rate of about 320 kilobit/sec. This means that initially synchronizing my library is a painful project, involving more than one overnight run. This is made worse by the fact that when they estimate what will fit, there's a bug where they don't factor in size reduction from conversion – maybe because you can't tell until it is done – compression can't be easily predicted. If you tried to just sync the whole library, it would tell you there's not enough room, so you sync some of it, then come back and do more later.

As it turns out, about 80% of my library actually fits on a 30GB Zune, and I was looking forward to getting an 80GB Zune so I could have all my music, and go buy a bunch more to check out new stuff, replace things that went away along with the ex and so on. Last night, I took home my shiny new 80GB Zune, and went to synchronize it. The sync is zipping right along, I'm happy that it is so fast, and I go watch a movie and come back. Uh – oh – problem – I now have about 1/3 of my library on the new Zune, and I've already consumed 30GB. Not good.

At one point, I'd been talking to a tech support guy and was griping about how long the conversion took, and he said they were working on that. Now I know how they fixed it – the bug was the conversion took too long (and it probably just takes a lot of cycles, no matter how well optimized the code), so the product team just decided to support lossless, now there's no need to convert, problem solved, there should be happy customers.

Unfortunately, this is a classic time vs. storage optimization. I want lossless if I'm putting the signal through my tube amp and into my Tannoy gold concentric speakers. My friend Otho is going to accuse me of being a barbarian for not using vinyl to create the signal. Using that level of quality for the audio output, even I can notice the difference between lossless and lossy. But nearly everything I'm likely to use the Zune to drive doesn't really have enough fidelity to make a big difference between 350 kbs and lossless – that's still about 3x FM radio quality. Storage space is more important. It starts getting even more important when you drop to a 4 or 8GB device.

I can now see what happened – customer problem was conversion took too long, solution was to not need to convert. What they forgot along the way was that with respect to storage, conversion is a _feature_, and as the customer, I ought to get to decide whether I value time, quality, or storage.

I'm still trying to sort out a way to bulk convert the whole library so I can solve the problem, and I hope the Zune team will give me back the feature they took away, which is to allow me to decide the quality level I want to store on the device.

PS – if someone out there has nice solutions for bulk conversion of about 3500 songs, I'd be happy to hear about it and will post the comment. If you want to turn this into an iPod vs. Zune .advocacy group, we're not going to do that here, and your comment will hit the bit bucket. If you like your iPod, I'm happy for you, but the point of the post was to talk about how we as developers really need to think through customer requirements and really need to be wary about taking away features – some customers might think they're really important.