Responsible Disclosure

Following Microsoft’s official response to the vulnerability disclosure we put out on Wednesday, we have been urged by all and sundry to reply. We do not feel at all comfortable participating in this public debate.

Resolution in private
From the very beginning we have sought to work with all the respective parties to remedy this out of the public eye. We privately disclosed the vulnerability and its use both to Microsoft and to the largest of the ad analytics companies currently exploiting the vulnerability—respectively on 1 October and 27 September. We made clear our belief that the Internet Explorer vulnerability was both significant and that its exploitation by an analytics company would suggest a disregard for user privacy and for the security efforts of browser vendors. Our suggestions were ignored by all the relevant parties as not being important. We then went through the standard channels for responsible public disclosure of security vulnerabilities. We put a disclosure notice up at Bugtraq and we also put a disclosure notice up on our blog. It isn’t for spider.io to judge whether this security vulnerability in Internet Explorer is important enough to fix. Equally, it isn’t for Microsoft and the various companies currently exploiting the vulnerability to decree unilaterally that this vulnerability is not important enough to fix. According to existing privacy standards, it is not ok for a browser to leak your mouse co-ordinates outside of the particular browser window. Should Microsoft fix this bug? This is a matter for the public to decide–in particular, it’s a matter for the privacy experts.

Two clarifications
There are two other points in Microsoft’s post which we believe are important to clarify.

Firstly, the post includes an ambiguous sentence: “There are similar capabilities available in other browsers.” It is important to clarify that other browsers do not leak mouse-cursor position outside of the browser window in the way that Internet Explorer does.

Secondly, it has been suggested that exploitation of the vulnerability to compromise login details and other confidential information is “theoretical”, “hard to imagine” and would require “serving an ad to a site that asks for a logon.” This is not the case. Ads do not need to be served to sites requiring login details. Ads need only to be served to some page which is open in Internet Explorer. The page with an embedded ad may be in a background tab. The page may be minimised. You may be using an entirely different application—potentially a different browser or some other desktop application—to log in. As has already been noted on Hacker News, if you were to log in at either this banking website or this banking website using any browser (perhaps using your Chrome browser, for the sake of argument), then you would be vulnerable to attack if you had another page open in Internet Explorer, even if Internet Explorer was minimised. There are many similarly vulnerable sites and applications. Making the problem of deciphering n-edged mouse traces over the keyboards at the two example websites that much easier, these are in a fixed position. A fixed position is not required: identifying an n-edged trace that would constitute a trace over a virtual keyboard is not difficult. But if the keyboard has a fixed position, then this is a problem that Android users know has already been solved with uncanny accuracy: e.g. by swype. To get a better feel for the problem of deciphering mouse traces, we suggest readers of this post try this deciphering challenge.