Quite some time ago, my wife was very sneaky. Oh, she’s sneaky again and again, but this is the piece of sneakiness that is appropriate for this post.
I logged on to woot.com one day, as I often do, and saw that there was a 30GB Zune for sale – refurbished, and quite a bit cheaper than most places had it for sale, but still more than I could plonk down without blinking.
I told my wife about it, and she told me that no, I was right, we couldn’t really afford it even at that price.
Then, months later, I found that my birthday present was a 30GB Zune – the very one from woot that she said we couldn’t afford.
Ever since then, I’ve been a strong fan of Zune and woot alike.
The other day, though, it dawned on me that I could use my Zune (now I have a Zune HD 32GB) to keep up with woot’s occasional “woot-off” events, where they proceed throughout the day to offer several deals. Unfortunately, I can’t actually buy anything from woot on the Zune.
I couldn’t figure this out for a while, and assumed that it was simply a lack of Flash support.
It’s not immediately obvious that there’s a difference between the Zune having no Flash support, and the iPhone having no Flash support.
But there is – and it’s a little subtle.
The Zune doesn’t have Flash support because Adobe haven’t built it.
The iPod doesn’t have Flash support because Apple won’t let Adobe build it.
I did a little experimenting, and it’s not that woot requires Flash.
I tried to logon directly to the account page at https://sslwww.woot.com/Member/YourAccount.aspx (peculiar that, the URL says “Your Account”, but it’s my account, not yours, that I see there. That’s why you shouldn’t use personal pronouns in folder names).
That failed with a cryptic error – “Can’t load the page you requested. OK”
No, it’s not actually OK that you can’t load the page, but thanks for telling me what the problem was.
Oh, that’s right, you didn’t, you just told me “failed”. Takes me right back to the days of “Error 4/10”.
The best I can reckon is that, since the Zune can visit other SSL sites, and other browsers have no problem with this SSL site, the Zune simply doesn’t have trust in the certificate chain.
That should be easy to fix, all I have to do on my PC, or on any number of web browsers, is to add the site’s root certificate from its certificate chain to my Trusted Root store.
Sadly, I can find no way to do this for my Zune. So, no woot.
I think this would – for a start, it would mean that users could add web sites that were previously unavailable to them – including test web sites that they might be working on, which are supported by self-signed test certificates.
But more than that, adding a new root certificate to the trusted root certificate store on the Zune is a vital feature for another functionality that people have been begging for. Without adding a root certificate, it is often impossible to support WPA2 Enterprise wireless mode. So, the “add certificate to my Zune’s Trusted Root store” feature would be a step toward providing WPA2 Enterprise support.
I’m not sure that the interface would have to be on the Zune itself – but perhaps the Zune could stock up failed certificate matches to pass to the Zune software, and then ask the operator of the Zune software at the next Sync, “do you want to trust these certificates to enable browsing to these sites?”
Similarly, for the WPA Enterprise mode, it could ask the Zune software user “do you want to connect to this WPA Enterprise network in future?”
I’ve written before on “Full Disclosure”:
Recent events have me thinking once again about “full disclosure”, its many meanings, and how it makes me feel when bugs are disclosed publicly without allowing for the vendor or developer to address the bug for themselves.
The post that reminded me to write on this topic was Tavis Ormandy’s revelation of the Help Control Protocol vulnerability, but it could be anyone that triggered me to write this.
If your motivation is to help secure users and their systems, then I think your disclosure pattern should roughly be:
[Obviously, some of the timing moves up if and when the exploit appears in the wild, but the order is essentially the same.]
It’s fairly clear that there are some people in the security research industry whose main goal is that of self-publicity. These are the show-offs, whether they are publicising their company or their services or just themselves.
For these people the disclosure pattern would be:
When all you’re in it for is the money, the answer is clear – you shop around, describing your bugs to Tipping Point and the like, then selling your bug to the highest bidder.
Sometimes this isn’t so bad – you get the money, and many of the vulnerability buyers will work with vendors to address the bug – all the while, protecting their subset of users with their security tool.
What a noble goal – you’re trying to make it clear to users that they have chosen the wrong vendor.
Here, the disclosure pattern is simple:
You may agree or disagree with a lot of what I’ve written above – but if you’re going to publish vulnerability research, you have to deal with the prospect that people will be watching what you post, when you post it, how you post it – and they will infer from that (even if you think you haven’t implied anything of the sort) a motive and a personality. What are your posts and your published research going to say about your motives? Is that what you want them to say? Are you going to have to spend your time explaining that this is not really what you intended?
As Tavis is discovering, you can also find it difficult to separate your private vulnerability research from your employer – this is perhaps harder in Tavis’ case to draw the line, since he is apparently employed in the capacity of vulnerability. If your employer is understanding and you have an agreement as to what is personal work and what is work work, that’s not a big problem – but it can be a significant headache if that has not been addressed ahead of time.
The story at the Financial Times is that Google has quietly stopped allowing their internal users – developers, testers, etc – to use Windows operating systems. Allegedly this is because they can’t trust the operating system after the “Aurora” attack earlier this year, in which systems at Google (and other companies) were compromised to steal credentials, email and source code.
Me, I’d like to think that this is just a bogus story – all operating systems have flaws, and when you’re protecting against an attack that is targeted against your company, rather than scattershot against an operating system at random companies, the protection afforded by running a non-majority OS is pretty much wiped out. In addition, a managed installation of Windows (i.e. a domain) provides for far greater corporate control that can be used in instances of attack to tighten security settings, or to monitor more closely the configuration and activities of those systems. Other operating systems just don’t have that level of manageability. So it seems likely that this is just some bluster on the part of the “Anyone but Microsoft” crowd, than actual corporate policy.
Or it could just be that Google wants its employees to run the Google Chrome OS more, or perhaps even that Google wants to spread its bets across different platforms – all of these would be good reasons.
But the question in my title remains – if Google does stop trusting Windows, and stop using Windows, what does that mean for Windows users? It would mean that testing of Google’s sites and applications under Windows would be an afterthought, rather than a focus. Instead of Windows being present in some part at all stages of development, Windows would be another Quality Assurance step – “now that we’ve built it, does it work on Windows without too many problems?”
It’s totally up to Google as to whether they wish to make that happen – certainly, if they see the bulk of their user-base coming from systems other than Windows, it would make sense to focus on those. But if you’re a Windows user, I hope this story makes you anticipate this as a possible behaviour, and one that could leave you without access to the Google resources – apps, documents, storage, email – upon which you rely.
So, what can you do?
Plan your exit strategy. How will you migrate your data away, and what will be your alternate applications? Or will you switch operating systems to follow Google? How will you decide when the time has come to make that change?
Of course, you can extend this discussion – what is your plan, Apple users, for when you have to choose between Apple and Adobe? That one may come sooner than any Google / Windows split.