Re: <nettime> Jacob Appelbaum on Skype (Skype interception - Project Chess)

[Joly MacFie <joly@punkcast.com>]

There was a response from a Skype engineer to similar concerns on Dave
Farber's IP list

http://www.listbox.com/member/archive/247/2013/06/sort/time_rev/page/1/entry/4:269/20130623090855:0B714E0A-DC06-11E2-9F35-8CD4CCA160A2/



---------- Forwarded message ----------
From: Matthew Kaufman
Date: Saturday, June 22, 2013
Subject: Skype / NSA
To: dave@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

On Mon, Jun 24, 2013 at 3:28 AM, Patrice Riemens <patrice@xs4all.nl> wrote:
>
> (bwo tetalab list)
>
> ---------- Forwarded message ----------
> From: Jacob Appelbaum <jacob@appelbaum.net>
> Date: Thu, Jun 20, 2013 at 4:08 PM
> Subject: [liberationtech] Skype interception - Project Chess
> To: "liberationtech@lists.stanford.edu" <liberationtech@lists.stanford.edu>
>
>
> Hi,
>
> I encourage all Skype users and security people to read this article
> about Silicon Valley and the spying world:
>
> http://www.nytimes.com/2013/06/20/technology/silicon-valley-and-spy-ag
> ency-bound-by-strengthening-web.html?pagewanted=all&_r=0

<....>



-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-



#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: http://mx.kein.org/mailman/listinfo/nettime-l
#  archive: http://www.nettime.org contact: nettime@kein.org