One of the Comcast twitter peoples saw my post and suggested I email the special help email account. While these posts have all been prompted by Comcast's push to kill analog cable, the topic at hand is more of the regulatory failures involved in digital cable than Comcast. But, I'm not about to pass up a chance to ask what I've been wondering, so I asked whether or not the service tier analog people are being moved to will be encrypted or not. Last time I heard the digital starter tier was encrypted, but that was 6 months ago.
In order to bulk move all the analog luddites like myself, they needed cheap digital to anlog converter boxes. Cheap, means no support for CableCARD. Now the FCC issued an integration ban back in 2007 that prohibits Cable providers from issuing converter boxes with integrated security modules. The integration ban forced them to start using CableCARD in their own equipment. I originally heard they were seeking a limited waiver allowing them to issue cheaper integrated boxes for limited purpose of porting their remaining analog customers to digital. I have been unable to determine if that request was approved or denied.
More recent evidence indicates the boxes have no support for a security module to begin with, but until I get my 2 free DTAs, I can't verify this. The integration ban only prohibits integrated security modules, it does not actually mandate that seperable modules exist. So a box without any security abilities at all would be perfectly permissible, it would also be even cheaper than an integrated box.
I'm hoping that my current analog channels are just transmitted in the clear since that will make it possible for me to build a DVR by just installing a QAM tuner card in one of my computers. I've been aware of the impending death of analog cable for a while now and have been putting off a DVR because of it. Yes, I still use a VCR.
My last post prompted some discussion of what CableCARD is and why it is not an acceptable solution on IRC amongst my friends. CableCARD's version of open access is about as open as the bottom of a locked filing cabinet in a disused lavatory in a basement without any lights and that has a sign on the door saying 'Beware of Leopard'.
The origins of CableCARD come from a 1998 FCC regulation requiring that the decryption module of a cable tv tuner be physically seperate from the rest of the tuner. CableCARD was a device and interface specification designed by CableLabs to comply with this regulation. Ideally this would mean that anyone could create a tuner that accepts CableCARDs, but this isn't quite the case. The CableCARD and the tuner do a key exchange to verify each other. For this key exchange to succeed, both devices need keys signed by CableLabs. Why? So that the CableCARD can re-encrypt the signal before sending it back to the tuner. Also, a tuner's key is only signed if it complies with the copy protection requirements of CableLabs.
The full failure of the FCC to enforce their 1998 rule can only be understood if the original purpose of the ruling is covered. The FCC ruling is the result of a provision in the 1996 Telecommunications Act requiring the FCC to adopt regulations allowing third party devices access to the cable tv system. The explanation for including this open access provision in the TCA is the 1968 Carterfone decision that forced Ma Bell to allow third party devices access to the telephone system. Of course there is a bit of a difference from what resulted from Carterfone and what has become of CableCARD. CableCARD is like telling Ma Bell she can't prohibit devices, but she is allowed to come up with whatever limits she wants. This includes making rules about what the phone is allowed to do with the signal long after it has left the phone system.
The supposed goal of CableCARD was to promote the same innovation that is possible in the telephone system through a physical card with a well defined interface. After the encrypted cable signal was processed by that card, the sky should have been the limit for innovation. Yet the requirements of CableCARD hinder innovation. The CableCARD compliant series 3 TiVo has more restrictions on what you can do with recordings than the series 2. It does not take a genius to figure out that they are missing because of CableCARD's limitations.
The gold standard for determining if a given regulation promotes innovation or should be what I call the two guys in a garage test, a reference to the origins of the Apple I computer. If two guys in a garage can't do it without outside help, then the regulation is not promoting innovation. Without the help of CableLabs to sign the host key, two guys in a garage can't make a CableCARD host device. Thus CableCARD fails the two guys in a garage test.
The idea that two guys in a garage can build a digital cable tuner is not ridiculous or far fetched. A software defined radio tuner built on top of a USRP and controlled by GNU Radio is well within the technical abilities of many engineers. An ATSC tuner was already developed using them in order to prove that the broadcast flag would never be fully enforceable.
Whether or not CableCARD complies with the letter of the 1996 Telecommunications Act or the resulting 1998 FCC regulations is open to debate, but I think it goes without saying that it completely violates the spirit of them. Remember, beware of leopards.
My cable provider, Comcast, has sent out a letter saying they will be dropping all analog cable service and going digital only in October 2009. With this change I will no longer be able to recieve cable tv without needing equipment from Comcast.
If only there was some part of the government that was supposed to be protecting my ability to use my own equipment on a cable TV system. Thats not wishful thinking, its actually part of the Telecommunications Act of 1996. The only problem is that the FCC considers CableCARD to be a perfectly cromulent solution to this.
The FCC is perfectly capable of truely enforcing the provisions of federal law that require the system to be accesible by end user owned equipment. The content providers will of course claim that they can't possible provide digital content without some form of protection. They've been doing so about digital TV since atleast 2003 when CBS stated:
If a broadcast flag is not implemented and enforced by Summer 2003, Viacom's CBS Television Network will not provide any programming in high definition for the 2003-2004 television season.
Here is a hint: today CBS and everyone else are broadcasting high definition digital content without the broadcast flag. Although it was't FCC that called their bluff, they fell for it. You can thank the EFF and ALA for stepping up and blocking the broadcast flag in court. Thanks to their efforts, there is no DRM in digital broadcast television.
The content companies use the same line to promote the idea that DRM is a necessary aspect of digital cable. This is the same message and the same bluff as before. The FCC needs to step up and actually require that the system be accesible in a DRM-free way to end user devices.
Consumers should be able to build their own DVRs that directly record the digital cable signal, but because of the failure of the FCC to protect their rights as consumers this isn't possible.
Congress decided to delay the DTV transition so I had to pick a new target for the mystery countdown. Feel free to guess what it is counting down until this time.
Previous countdowns have been:
* Presidential Inauguration
* Shopping days until X-mas 2009
* DTV Transition
Nope, my ad block software is working as designed. Thank you for asking though.
My KVM has herpes :P
A few years ago I wrote a program that generates a highly compressed PNG file. Something on the order of a ratio of 1,000 to 1. This was all fun and games, but the output files I have (I lost the source code) don't do much of anything to modern computers. 1 GB just isn't very impressive by today's standards. So I took it to the next level.
Using bzip2, I wrote an app that does a ratio of about 1,800,000 to 1. Strangely enough 0x00 is not the optimal byte to compress with bzip2, 0xFB is. This is due to the first pass of bzip2 being RLE. Any sequence over 4 bytes long is converted into 4 bytes followed by a length byte. The highest value that can appear as the length byte is 0xFB (251). Obviously this means any stream of 0x00 is converted to a sequence of 00 00 00 00 FB, which is less than ideal. Streams of 0xFB on the other hand are converted to FB FB FB FB FB.
Bzip2 also compresses in blocks with each block containing up to 45,899,235 bytes. A stream of 0xFB compresses down to blocks 26-bytes long. I can pre-compute the checksum of a single block and just dump it to a file repeatedly! Thus is born my latest toy program.
1 TB file
Source code
Some day I may rewrite my app that makes giant PNG files and actually put some thought into how the deflate compression algorithm works and what uncompressed PNG chunks look like. I may be able to improve on the 1,000 to 1 compression ratio I obtained with the original.
My firefox extension is coming along nicely. I have the easy part of it done and I learned some cool stuff. Like how putting chrome://browser/content/browser.xul into the address bar can get you tabs within tabs.
I also fixed the scrollbars in the theme I have for Firefox on my work lappy. (The default OSX theme is icky)
My former roommate wrote a module for unrealircd that enabled unicode nicknames. I'm currently a hammer and sickle on IRC. :D
☭
Its really messing with some people's terminals, especially the nicks that are in a RTL alphabet.
Update: I found the swastika in the unicode tables while trying to find a symbol that would make a decent pacman. The left and right handed versions are below. Yes, I'm using one of them as my IRC nick.
卍 卐
I'd like to note before anyone without a sense of humor complains, that the swastika was originally a symbol of good luck. Not that this will stop any people without a sense of humor from complaining.
![[setec astronomy]](/graphics/sa/sa.png){kind=small}
