TrueJournals

I can’t believe I haven’t written a blog post about Net Neutrality.  For those of you who know me personally, you should know that I’m a very strong supporter of Net Neutrality, and believe it’s very important that we make sure the Internet is kept neutral.  However, for whatever reason, there are a LOT of misconceptions about Net Neutrality, and what exactly it entails.  Since Net Neutrality in reaction to Comcast has once again come up in the news recently, I figured I should write a blog post about the subject.

First, let’s go into some background on the Comcast case.  A year or so ago, Comcast decided that its network was being congested by too much P2P traffic; namely, traffic from the BitTorrent P2P protocol.  So, they decided that they would clear their network of this congestion by carefully denying BitTorrent connections.  They did this by looking into the traffic that BitTorrent was sending over the network, and sending back false information so that connections to peers would fail.  The actual details of how this was done is outside the point of this post.

After some outrage from Comcast customers who used BitTorrent, the FCC decided it would step in and tell Comcast to stop or suffer consequences.  As soon as this happened, there was some question about whether or not the FCC actually had the power to do this.  But, the case went to court and a judge decided that the FCC did have the power to do this, and that Comcast had to stop denying BitTorrent connections in this way.  This was a major win for users of the Internet: the court decision basically meant that your ISP can’t deny you from accessing information on the Internet. (continue reading…)

I will continue to update this post throughout today and tomorrow with the latest developments of my caller ID research.

Sunday, 9:30 AM –I’ve discovered an interesting line while decompiling Comcast’s software (in an if statement which handles incoming messages):

(arg1.from[0].match(CALLER_ID_SERVICE_JID) || arg1.from[0].match(CALLER_ID_SERVICE_JID_TEST))

This means that comcast IS checking who the message is coming from.  Although, they seem to do something else if it’s not from one of these two addresses.  Also, what is CALLER_ID_SERVICE_JID_TEST?  I’ll have to do some more exploring!

Sunday, 1:44 PM — Hmm… some interesting declarations:

public static const CALLER_ID_SERVICE_JID_TEST:String=”vismedia02@comcast.net”;
public static const CALLER_ID_SERVICE_JID:String=”callerid_alert@comcast.net”;

Monday, 9:19 AM — I’ve discovered an interesting URL in the code — machenmusik.com — it’s the package for the caller id decoding function (so, the project should be hosted there).  However, it currently just gives a login prompt.  Very strange.  Anyway, I’m attempting to translate the caller ID decoding into python.  I’ll let others translate it from there.  We’ll see how this works out…

Monday, 3:18 PM — Well, after playing with the decompiled actionscript a bunch, I can’t get it to return any comprehensible output.  The same goes for the python I translated.  So, I’m kinda giving up right now due to lack of knowlege.  If someone else would like to pick up where I’ve left off, contact me and I can send you what I have so far…  It was worth a try, right?

Comcast has recently added a new feature to their digital voice service: caller ID anywhere.  Simply download a program on your computer, enter your comcast.net username and password, and you’ll get a small alert any time you get a call.  The same system allows comcast to show caller ID alerts on your TV.

So, how does this work?  Did comcast come up with some super-secret way to encode this data so no one but them can use it?  Nope; they’re simply using XMPP.

For those unaware, XMPP is a very nice concept: an open messaging protocol.  This means that companies don’t need to invent their own protocol, or shell out big bucks to use another protocol.  Just grab a server and client, and you have an instant messaging system.  XMPP is also designed to be expandible.  Is there a feature you need that it’s missing?  Just code it in, following the current specifications.  The problem with this is that different clients can conform to different specifications for things that aren’t part of the official protocol, but that’s another discussion.

Comcast decided to not reinvent the wheel, and just use XMPP, with a little twist.  If you already know a bit about XMPP, I’ll give you the stanza as a client receives it: (continue reading…)