先日、バッファローやIOデータからパソコン向けのデジタルテレビチューナが発売されました。

http://www.watch.impress.co.jp/av/docs/20080423/iodata.htm

これまでは、家電メーカが発売するデジタル放送対応HDDレコーダか、デジタルチューナを最初から内臓した パソコンでないとデジタル放送を録画するのが困難でした。しかし、外付けデジタルチューナでPC自作派もテレビ録画ができるようになったのです！

よーし、1TByteのHDD4本・・いや8本のっけたテレビサーバつくっちゃうぞ~

物欲は膨らむのですが、そのまえに気になったのが、デジタルチューナのデータ暗号化の仕組みです。

よく知られているように、電波事業者の既得権益を守るために日本では「コピーワンス」という著作権保護の仕組みが定められています。簡単にいうと、録画した番組を他のパソコンやDVDなどにコピーするには、元のデータを削除する必要があるという、実に利用者(・・・製品開発者)のことを考えない仕組みです。不便でしょうがないでしょう・・・。

コピーワンスを遵守するには、当然移動する先の機械もコピーワンスに対応している必要があるので、機器間で認証できる必要があります。そのため、これまでは「認証されたチューナー」と「認証されていない自作パソコン」という組み合わせを許すような、パーツでの販売が禁止されていたのです。

海外ではデジタルチューナなんて50ドル切るご時世なのに、なにが悲しくて2万円以上も払わないといけないかというと、上の画像でみてわかるように青い「B-CAS」と書いてあるカードのためです。暗号化データの複合キーをB-CASカードがもっているために、余分な回路が必要になるのです。

公共の電波使ってんだから、暗号化せずに放送しろよ！

もちろん彼らの建前は著作権保護です。しかし、そんなの嘘っぱちです。

今回のデジタルチューナカードの単体販売が許可された根拠になる通達「ＰＣ用デジタル放送チューナのガイドライン（PDF)」があります。この中の一文をみてみましょう。

4.4 受信機の入力の制限
· コンテンツ保護規定で規定される機能要件のとおり、MULTI2 によって暗号化（スクランブル）されているがローカル暗号化されていないコンテンツについては、PC 用デジタル放送チューナユニットの入力（アンテナからの入力）以外の受信機入力を有してはいけない。例えば、ファイルの読み込みやネットワーク等を経由して、MULTI2 暗号がかかったファイルやストリームを読み込み、デコードできてはいけないことなどをいう。

暗号化されたデータを複合していいのは、キャプチャカードからの入力データだけで、他の経路で入ってきたデータを複合してはいけない・・・ってことですよね。

また、MULTI2 暗号がかかった状態（スクランブルされた状態）であっても、ローカル暗号化せずに出力（ユーザアクセスバスを含む）あるいは記録してはいけない。

ローカル暗号・・・これは、機器を作ったベンダー固有のアプリケーションによる暗号化なしには保存してはいけないってことです。つまり、ログかしたデータはバッファーローやIOデータのテレビViewerを使わない見られないってことですよね。

まじで！？

バグだらけで、使い難い、ハードウェアベンダーが適当につくったテレビViwer限定なの！？orz

しかし、ソースコードが公開されていないようなベンダー固有のソフトでも、有志がパッチを作ってくれるという希望がのこっています。

4.9 ソフトウェア等の耐タンパ処理
· ソフトウェアの実装においては、コンテンツ保護規定で規定される実装基準のとおり、コピー制御情報の改ざん防止や、ローカル暗号の鍵及び保護の対象の不正な抜き取り防止など、耐タンパ処理等によるアクセスの防止措置について特に留意すること。

「放送番組及びコンテンツ一意性の確保に関する開度ライン（PDF)」・・・・・・これもひどいけど、これの話じゃないなあ。

コンテンツ保護規定って ARIBのTR-B14、TR-B15あたりっぽい。ARIBの資料って確か公開してない記憶があったのですが、Google先生がみつけていましたので、リンクはっておきます。( TR-B14 分冊 1-1、1-2、2、3、4  TR-B15 分冊1、2、3、4  分量多すぎ・・・これが池田先生のいうところの、無意味な政府主導の国内でしか通用しないISOか・・・。）

ソフトウェアのTamperproof性能を確保するって意味かと思って読んでみましたが、コンテンツ保護規定のある第八編にはソフトウェアの耐タンパについてなんにも触れてないなあ。他にも、ローカル暗号化の方法や、暗号鍵の保護の基準が書いてあるかとおもったけど書いてない。

たぶん、メーカによって開発能力に差があるから、技術力の低いメーカのソフトからローカル暗号用の暗号鍵を抽出できるはずです。まだ、有名どころメーカしか機器をだしていませんが、弱小や後発はメーカは市場の人気を取るために、あえて簡単に突破できるように暗号化機能、鍵の保管をするかもしれません。

実に、楽しみです！

しかし、電波利権に巣食っている人たちって見苦しいよな・・・。

最近Googleの提供しているサービスは多すぎて網羅し切れていないのですが、また新しいサービス「Google App Engine」を展開しました。残念ながら、アカウントは限定公開なので先着1万名さまで取得することはできなかったのですが、SDKがダウンロードできるので、簡単になかみを調べてみました。

まず、インストールにはPythonが必須です。Windows環境ではActive State社からActive Pythonが出ているので、インストールしないといけません。

・・・開発言語Pythonかよ！

この時点でそうとうゲンナリなんですが、Installerで開発環境をチェックしているのでちょっと好感がもてます。

インストールといっても環境変数にPATHを設定するのと、ファイルを展開するだけのようで、下記のフォルダのような中身が作成されます。

さて、さっそくDemosでも動かしてみるか・・・とおもってdev_appserver.pyを起動してみますが・・・うごきません。orz

>dev_appserver.py demos\guestbook\

opener.add_handler(urllib2.HTTPSHandler())
AttributeError: 'module' object has no attribute 'HTTPSHandler'

なんとなんと、HTTPSなぞしらぬと申されるか！ コメントアウトしちゃおう・・・。

そうすると、Allow dev_appserver to check for updates on startup?( Y/n )とくるので、Noを選びたいところですが、Yesを選択。

INFO     2008-04-14 12:34:32,858 dev_appserver_main.py] Running application guestbook on port 8080: http://localhost:8080

お、無事動きました。

ざっくりLibを見る限り、これってPhythonである必要性ないよね・・・。Ruby、PHP、Perlでもいいんじゃないかとおもうんだけどなぁ。

いまのところ慣れたASP.NET環境を離れて、Google App Engineでプログラムを組む強い動機はみあたりません。GFSやBig Tableは魅力的だけど、データセンターにラックと回線借りてる人間には必要性低いです。この前ちょこっと負荷テストしてみたのですが、20万円のサーバで、IISサーバは1000Request/sec処理できます。

Googleのデータ資産を扱えるなら魅力もあるけどファシリティだけなら自由の効く環境のほうが、サービス黎明期にはいいとおもいました。

http://builder.japan.zdnet.com/sp/google-app-engine/story/0,3800086196,20371257,00.htm