I’ve noticed a few posts wondering why we encrypted the stream (and lots of assumptions, both good and bad), and I realized I should’ve explained when we posted the build. We’ve actually been planning to enable encryption for quite some time, this just happened to be the build in which it went live.
Our goal with the Slingbox is to have a device that not only offers consumers new freedom in their ability to placeshift their content, but also a product that protects the rights of the content owners and creators as a whole. Additionally, we feel protecting the stream also helps secure your rights and privacy as a consumer. To this end, enhancing SlingStream protection has been on our roadmap for quite some time.
Unfortunately, it’s clear that the Applian At-Large Recorder has gotten caught in the middle of this. As a small company, we haven’t had the resources to properly support third-party developers at present, although it is our goal to eventually have an API or SDK for third-parties to use. If you consider the numerous ongoing software developments we have at Sling (Windows, OSX, Windows Mobile, other platforms, etc), we have to pick and choose where our engineering efforts go extremely carefully, and while we have very ambitious goals, we still have a lot of realities to deal with!
On a technical note, a few people have surmised that the encrypted stream either increases CPU overhead or decreases stream quality. We have done quite a lot of testing and have not seen these negative results. Our tests show the encrypted stream in the new beta firmware performing side-by-side with the unencrypted stream in the current firmware with no difference. Don’t forget: if you are not doing exact side-by-side comparisons, no two streams are exactly alike!
I hope this helps clear up the issue. I welcome any feedback and comments.