Skype's ominous link checking:

Facts and speculation

By Jürgen Schmidt

Our discovery that URLs sent through Skype are then visited by Microsoft has caused quite a stir. A little more information has now emerged and leads to even more questions.

Early this week, The H reported on how heise Security had discovered that links sent in private Skype chat sessions were being visited by a Microsoft system shortly afterwards. They found that only HTTPS URLs were accessed, and that Microsoft used all the transmitted information – including any session or user IDs that are often contained in HTTPS URLs. Pages were accessed via HEAD requests, which means that only administrative information was retrieved, but no page content.

The facts of the report as published were confirmed by several independent experts. Although we didn't register any visits to any of the insecure HTTP URLs that were also sent, we have since received credible reports that Microsoft sometimes also accesses these URLs.

There have been speculations that the issue is caused by a security feature that is part of Microsoft's SmartScreen Filter. While this is a very plausible working hypothesis, it creates more questions than answers. The first such question is: why is the check carried out with a time delay of several hours, rather than immediately? Time is a critical factor in active spamming or phishing campaigns, and checking URLs that are several hours old can at best serve only documentation purposes.

The next question is: how does Microsoft intend to rate a page without knowing its content? Potential explanations referring to a reputation database are not valid if no reference data is available for the pages – as was the case with the URLs that were specially generated for our test. Neither are we convinced by the suggestion that the only purpose of the HEAD request is to discover potential redirections to known malicious pages. Firstly, such a redirection could also be triggered in the HTML code that has not been retrieved (meta http-equiv="refresh"), and secondly, many web pages embed the actual malware code via iFrame tags – which is not included in the HEAD data either.

Finally, the use of the SmartScreen Filter technique is documented, for example in Internet Explorer, and users can choose to disable it. Not so in Skype. There is no concrete information to suggest that SmartScreen filters are being used in Skype chats, and Skype users have no way of declining the use of this surveillance technique.

Despite all this, it is likely that the observed access activity is connected to some form of security feature. However, if this is the case, the feature has been poorly implemented. It has very few potential benefits – especially in view of the rather substantial invasion of users' privacy. After all, Microsoft purposefully accesses even personal information that is not intended for third parties – such as the URL to a private photo album of a family trip that is sent to mum – and then stores this information on its systems. Microsoft should at least document the use of these surveillance techniques and provide users with the option to decline the well-intended security measure.

No further access attempts from Redmond were observed during our latest link-sending tests in Skype. Let's hope that Microsoft has learnt from this debacle and disabled the feature, at least temporarily. This would be a good time to meditate on the problem, think carefully about the costs and benefits of such surveillance features and then contemplate how to implement them properly. Incidentally, similar tests carried out in the Google, Facebook and ICQ chat clients returned no results – which means that no access attempts were registered on the special URLs that were sent via these clients.