« CES Consumer Electronics Show | Main | CES Overview »

It's not Skype....

I heard a rumor yesterday about a post by Andy Abramson on Skype and SAM. Frankly I believe he should print a retraction. I'll use the comments posted on Jeff Pulver's blog to add clarity. Jeff also passed on a posts without some more detailed fact checking. Tom Keating did the same. Industry leaders with their facts wrong.This is a shame. I also don't buy the slant on Andy's Skype Responds either. It's still out of context and there are no links on the post to the third party product SAM or Skype.

This is not a security hole in Skype. It is the result of using third party beta software in development for use with Skype. His problem.. that SAM connected two calls is listed in known bugs. As for the technical issue of recording "encrypted" calls this is complete hogwash. I can record all sorts of call and it makes no matter if it is an X-Ten softphone or Glophone etc. You'd also get the same result if you ran two softphone clients at the same time on the same soundcard and answered both calls.

Peter Macaulay comments: This is not a security flaw -- this is a feature! : - ) It is just as if you were sitting in my office and an incoming POTS call is picked up by my 20 year old answering machine. If the volume is up everyone in the secure space (my office) can hear the recording. Solution: Mute the answering machine. Remember how folks used this feature to screen calls -- "Hi it's Sally, if you are there please pick up". We just need to learn how to use these new tools. When you have a meeting you mute your answering machine -- that should be the default. Andy Abramson posted this as a Skype security flaw as if it were a programming memory leak -- no it is just the mixing of your voice on the speaker. I will leave my Skype/SAM running in my hotel room while I am at CES today -- just need to mute the speakers so I don't scare housekeeping -- and have my messages overheard! The bigger issue is that this implied flaw is from the Skype/SAM combo created by Skype publishing their API. I would hate to see Skype shut down their API which is already creating many new products such as the Siemens handset and also the Actiontec gateway just announced at CES this week. Just my thoughts on a cold night in Las Vegas

Andrew comments:
I was on the conference call taking place at the time Andy called and I would just point out that the version of SAM my colleague was using was Beta software (the version in use was 0.9.30, the then-current release) and that this is a documented known bug (http://www.freewebs.com/skypeansweringmachine/help.htm#33418068): "2) SAM answers incoming call even though user is in an active outgoing call. You get a audio mixture of the current call, SAM and the incoming caller." I am not diminishing the importance of Andy's point, merely adding context.

The Jeff Pulver Blog: Andy reports major bug in Skype Voicemail!

There is a brave new world of developers out there creating some interesting new VoIP applications. They need encouragment not a flamepool. It's obvious that Skype will launch an "Authorized by Skype" program too. Issues around new products and functionalities are important. Sometimes even bugs have become new products.

Just think. If you run two profiles (names that will get searched!) of Skype on your PC. Set them both to auto answer... and employ SAM as it is now. Then you could connect random strangers. Even more the first caller could keep an open line and wait for another person to call the other line. Then I guess that would make the listener a voyeur. Have fun kids! Now... is that a security flaw? I doubt it. Common sense works wonders too.


Listed below are links to weblogs that reference It's not Skype....:

» Skype Security Issue Part2 from VoIP Blog - VoIP News, Gadgets
A couple days ago I quoted Andy's blog where he discussed a Skype security issue whereby callers in a Skype conference could hear an incoming caller leaving a voice message vis Skype new SAM (Skype Answering Machine) feature. Well, that... [Read More]

» Andy, Jeff and Tom are Wrong Yet The Earth Still Spins? from Rich Tehrani - VoIP Blog
If you haven't been watching, you missed some some serious Skype controversy in the blogosphere. Some of the most frequent and best-known VoIP bloggers Andy Abramson, Jeff Pulver and Tom Keating are wrong according to this post from Stuart Henshall... [Read More]

» Recording Regulations and VoIP from Aswath Weblog
There was a storm in a teacup over use of Skype Answering Machine and Skype. I have already commented on this point. But what is interesting is that both Andy and Stuart introduced the legality of recording conversations. I had... [Read More]

» Skype Security Issue Part2 from VoIP Blog - VoIP News, Gadgets
A couple days ago I quoted document.write("Andy's blog""); where he discussed a Skype security issue whereby callers in a Skype conference could hear an incoming caller leaving a voice message vis Skype new SAM (Skype Answering Machine) feature. Well, ... [Read More]

Comments (6)

Andy Abramson:

Why should I retract a fact that happened?
Why should Skype not have commented when asked?
Why would both people on that call have emailed / skype chated with me and reported hearing the other's conversation.

Fortunately, we're all under NDA's of a mutual nature, so no harm, no foul, this time. Sure we know it's Beta, but when Microsoft software has a bug everyone jumps all over them.

The fact that something is documented as a "feature" in a piece of software that creates something akin to spyware is hardly a reason to defend something. The fact that it is BETA, is also not a reason to defend it.

I think the idea of SAM is great, and look forward to that type of application working. But, given what happened, and being that I was one of three people who were party to it, I have a right to report what happened.

By contacting Skype and getting their comment directly from the USA PR contact I nipped this at the bud. Sure it's a set back for SAM, short term, but longterm I hope they create a better product that is secure. The fact that one party can hear the other is a flaw. Documented or otherwise.

FYI, I was not the person running SAM, the person I was calling was. How should I know what that application's known flaws are? Why should I care?

I want to see the community flourish. By raising a problem, hopefully the hole will be plugged.

Andy Abramson:


In the USA it is illegal in most states to record a call without the other party being advised. In some states a beep tone every so many seconds is required.

While this may not be known by many, it is indeed the law. It's called Wiretapping and even though this is the digital realm, recording a person's conversations without their knowledge, by phone, or even in the same room or by shotgun mic is against the law.



From a technical point of view this "bug" is bigger than Skype. It is indeed an issue that needs thoughtful discussion and development.

From a consumer perspective you were on a Skype call when it happened. Thus easy to draw the conclusion that it is "Skype". In fact one of the users in your conference call compromised everyone's privacy by connecting two inbound audio streams over the same audio card. There are many ways to compromise your privacy using a PC. That you heard someone else (and stopped I presume) was probably better than hearing it on a podcast later.

However, exactly the same thing would have happened if you had another answer machine set up to answer say voiceglo inbound call, while being on a Skype call. Unless the second line is managed through a separate sound card you will have problems. I don't think SAM is alone in illustrating this behavior. SAM should build in a switch that says.. if Skype is already in a call then SAM is disabled until that call is terminated. There is a good reason for this fix apart from your own experience. It means that other callers can be added to the call if you desire etc. It will also enhance Skype's own voice mail product.

Another example of a possible SAM fix is that it could refuse to engage in a voice message when a call is on the line, however it could send a text message (which it does already). The text message could say.. SAM is currently engaged. Please text your message or ring back later... or some such. This is just the type of option that SAM can do by integrating with the Skype API. For the product to come authorized Skype may need to make some decisions about the above.

What's required is a constructive debate about the future of call privacy. From the little testing I've done on recording there are many things we can do with computers that were never possible with the telephone. A new understanding is required.

There are some very neat things that can be done for providing records, text confirmations, mutual disclosure, records etc. So where we should be looking is call recording. Like you I'm well aware of the wire-tapping laws. I already posted the laws some weeks back. Consumers need some signals when recorders go on. They also need some simple contractual exchanges with escalating forms of disclosure. I blogged briefly on this just after releasing instructions on SkypeCasting. I also like the approach used in that solution as currently you must add the "recorder" to the conference. Thus even if it is not active, all parties know it is an option.

This is a great creative space that can generate new products and new solutions. There are many experiments going on with people using recorders on different machines etc.

You should know it is possible to record you on Skype and on any VoIP softphone using Windows Sound Recorder without you knowing. No extra equipment is required. There is no difference here than with me inserting a recorder in to a land line call. From my perspective without your knowledge that would be not only illegal it would also be unethical.

Still you are also at the other parties mercy. In the future you may want to use the Skype API to confirm that the other parties PC is managed in a way that won't compromise your call.

From my perspective time to reinvent something that was broken and where the law possibly should be revisited.


Wouldn't a bus signal suffice when one session is going and another call comes in?

Also, your being more defensive than the Skype folks were. They were most thankful and more sensitive to the implications. I guess when it's your bread and butter they can be that way.


Interesting debate developing here and one that I at least am finding pretty educational. A few observations:

1. I am not too technical so I didn't reflect on the fact that in a VoIP sense the fact that my PC only has one soundcard is equivalent to having a "party line" (remember those?) There is no way I can keep the incoming and ongoing calls separate as they both use the same resource to turn them from bits into waves (or vice versa).

2. Against that background I now understand that my desired behaviour is probably not possible to achieve (at least not on my current PC with only one soundcard). This would be that SAM realizes I am engaged on another call, plays my greeting and picks up the message from the inbound caller without disturbing my ongoing call or mixing the two.

This is akin to the functionality I am used to from my mobile and landline phones - but there the functionality is implemented in the network and that's what makes it possible. Skype is ostensibly P2P and so the functionality (a la SAM) is implemented at the edge. It's exactly the same reason my old fashioned answerphone will only collect a message on no answer, not on busy. Ah! It's all starting to fall into place...

3. I don't agree with Peter that this is analagous to someone in my office overhearing my answerphone (although I realize he might have been kidding here). The difference is that neither of them are in my office and I believe the analogy breaks down right there.

4. SAM's authors have logged this as a known bug (NB not an enhancement request) implying that the program is not behaving according to its spec. I wonder what the specified behaviour is? Given the implications of points 1 and 2 above (if correct) I assume this would be to reject the inbound call and possibly generate a text message to that effect to the inbound caller. A (secure) audio response to the inbound caller would, by an extension of the same logic, presumably not be possible to generate.

5. As an aside, I wonder why Skype has not implemented a presence state "On a Skype Call". This could presumably be used, not only by Skype API applications such as SAM, but also by Skype itself to implement some kind of "call waiting" functionality where the user can control which of two calls has access to the sound card (i.e. "live" line) while the other one is "parked" - but in such a way that the two calls are kept separate at all times.

In conclusion I find it hard to believe that this is a "feature" (Peter kidding again?) or that it would be considered desirable behaviour by many users. The program's authors obviously consider it a bug. I think it was legitimate of Andy to raise the security issue and spark this interesting and (at least for me) educational debate.

Now I am just left wondering if someone is going to be able to implement the "secure multi-line" functionality that I, and I suspect many others, desire.

Andrew, I just think it hasn't been done in the SAM application. The data is there and available in the API.

The API does nothing with Audio Streams.

The Audio is only available through the Skype>File>Options>Hand/Headset: Audio In and Out. The user directs this to the sound card of choice on the Voice Tab in Control Panel.

The API is neither restrictive nor non-restrictive. It is simply a set of messages sent to & from API to Device or Software Application.

SAM isn't using all of them or using them effectively. If it was.. SAM might be safer for answering Skype Calls than other recorders that my not use the API and are engineered to capture the media stream. Without an API connection you will never be advised of these.

Andy, I think that answers your question. Why can't a bus signal be used? I think it is already there, it was not used. On the Skype response your "voice" is heard and influential... bad press is scary and all I meant to infer was their response seemed to be less than well thought out. Looking at the API shows that Skype is not opening up their Audio streams. They have to allow you to plug a headset in.

I responded because anything that might close down the API is detrimental to creating a more interesting and potentially safe market for communications.

In retrospect I should have spent a little more time spelling it out rather than using a couple of comments and pushing post. Put it down to post CES exhaustion.

My Furl


Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.32