The characters ‘http://:’ in a chat message can trash a Skype installation beyond repair
Wed 3 Jun 2015
A thread at Skype community forums has brought to light a relatively unusual, but extremely critical bug in Microsoft’s Skype clients – one only has to type the invalid URL initiator http://: into a text message and send it in order to damage your installation of Skype so critically that it will need to be reinstalled.
The community member Giperion notes prosaically in the thread that ‘clearing chat history not helps, because when skype download chat history from server, it will crash again’.
The defect affects Skype for Windows, iOs and Android, whilst the OSX and Metro-style Windows installations are unaffected.
According to Venturebeat’s test-to-destruction experiments with the bug, one could effectively kill the installations of other users on the affected platform by sending them a Skype text-message with the offending characters from an OSX or Metro install. Effectively one could hold the ‘victim’ to ransom, since the only way they will be able to recover their account is if the sender of the message deletes it. Even then one will need to install an older version and await a skip-update when Microsoft release a fix. However this is not possible on iOs and Android, which enforce strict version limitations based on the current OS version.
Signing in to an account that already had the killer-characters in its history causes no crash on Android and iOs, and neither does sending them from those platforms.
It seems that the extended local file saving on full-fat installations in Windows causes fatal configuration issues by trying to parse the (presumably unescaped) meaningless code in a meaningful way. A reasonable guess would be that the program is trying to create clickable URL resources for visualisation in chat windows within the program.
The Linux-derived mobile operating systems instead have to receive the http://: characters in order to crash, presumably because the Skype chat log is saved to a cloud resource unaffected by the bug, rather than locally. However, these are guesses based on the (admittedly pointless) amusement of trying to type CLOCK$ into a filename into Windows iterations of the last 10 years or so.