---------- Forwarded message ---------- From: *Matthew Kaufman* Date: Saturday, June 22, 2013 Subject: Skype / NSA To: da...@farber.net

Dave, for IP:

I'm a long-time IP list reader and also Principal Architect for Skype, and I'd like to address a few of the things below...

*Ridgely Evers* wrote:

John,

That's a fine distinction; the fact is that the management of Skype -- even when they were owned by eBay -- told the US Government to stick it, and got away with it.

I'm obviously not in a position to comment on what Skype can and cannot log or intercept, nor how and when that data (if any) is passed on to third parties. Microsoft has made statements about this aspect already.

The very architecture of Skype made that relatively easy to do. From its inception all communications were strongly encrypted. In addition, it was peer-to-peer, making it nearly impossible to wiretap.

As a consequence, people who were concerned about privacy -- including many of us in the security industry -- used Skype for secure communications.

Both eBay and Silverlake maintained this architecture, as well as the Luxembourg HQ.

Since being acquired by Microsoft, however, the service has been re-architected to run through MSFT-owned servers, rendering encryption functionally meaningless and making it just as easy as POTS to monitor.

None of this -- neither the $7.5B acquisition itself, nor the decision to move to a datacenter model -- make strategic or business sense for Microsoft as far as I can tell.

It's not the first really dumb thing they've done, but it makes me suspicious, especially in light of recent news.

Ok, so I take issue with it being "really dumb", and I'd like to explain why:

First is actually a more subtle issue... the Skype peer-to-peer network architecture elected certain nodes to be "supernodes", to help maintain the index of peers as well as handle parts of the NAT/firewall traversal for other peers. This election algorithm chose only machines with open Internet connectivity, substantial uptime, and which were running the latest version of our peer-to-peer code. The last bit unfortunately meant that most of the time, the election winners were a monoculture of Windows desktop machines running the latest Windows Skype client. This proved to be a problem when not once, but twice a global Skype network outage was caused by a crashing bug in that client... bootstrapping the network back into existence afterwards was painful and lengthy, and that is in part why Skype has switched to server-based "dedicated supernodes"... nodes that we control, can handle orders of magnitudes more clients per host, are in protected data centers and up all the time, and running code that is less complex that the entire client code base. (And this conversion started well before the Microsoft acquisition was even announced, during the Silverlake era.)

The second is really what is driving Skype to move not just the supernodes but actually many other parts of our calling and messaging infrastructure "to the cloud", and that is the amazing growth of mobile and tablet computing. The Skype peer-to-peer network, and many of its functions (such as instant messaging) was built for a world where almost every machine is powered by a wall socket, plugged into broadband Internet, and on for many hours a day.

Over the past few years, the number of Skype users who are using Skype from iOS-based phones and tablets, Android-based phones and tablets, Windows Phone-based phones, and Windows RT tablet devices has gone from a tiny percentage to a significant fraction of our user base. And these devices are a lot different: they're running on battery, sometimes on WiFi but often on expensive (both in money and battery) 2G or 3G data networks, and essentially "off" most of the time. On iOS devices, applications are killed and evicted from memory when they attempt to do too much background processing or use too much memory. On Windows RT and Windows 8 Modern applications, when the application is not in the foreground we only get a few seconds of CPU execution time every 15 minutes and again, strict memory limitations if we want to stay loaded. And when the Skype application is unloaded, it can no longer receive incoming calls or IMs, rendering it a lot less useful.

If you've tried to use Skype on a mobile device, especially if you have a lot of contacts or a lot of IM conversations, you'll discover that it rapidly becomes a battery-powered hand warmer, and drains the battery faster that probably any other well-known application out there. And this is because it, until recently, was participating as a full node on our peer-to-peer network... exchanging packets regularly (over your 3G radio, most likely) with every single one of your contacts to keep presence status updated, exchanging packets with everyone in every IM conversation to keep those conversations synchronized, etc.

And you probably also have started to notice things like missed IM delivery, as the peer-to-peer delivery algorithm requires that both the sender and the receiver be running at the same time in order to deliver a message... not a problem with two broadband-attached always-on PCs, but rare if you're both on Windows Phone or Windows RT tablets that only run that algorithm when the application is in the foreground or for 3-5 seconds after it is backgrounded.

How do we solve that for our users? Servers. Lots of them, and more and more often in the Windows Azure cloud infrastructure. In the case of instant messaging, we have merged the Skype and Windows Messenger message delivery backend services, and this now gets you delivery of messages even when the recipient is offline, and other nice features like spam filtering and malicious URL removal. For calling, we have the dedicated supernodes already, and additional services to help calls succeed when the receiving client is asleep and needs a push notification to wake up. And over time you will see more and more services move to the Skype cloud, offloading memory and CPU requirements from the mobile devices everyone wants to enjoy to their fullest and with maximum battery life.

Making this transition has been difficult and taken the hard work of hundreds of developers, especially to make it as seamless as possible for users who don't particularly care how we get it done or that we are changing it... but I would say that it makes strategic and business sense to be doing, otherwise we wouldn't bother, and I hope the above at least partially explains why I think that.

Matthew Kaufman