雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2003-05-18

image.rbの最新改造版

tDiaryの開発版のほうには,すでに私の出る幕は無いような気もしますが,少し気になる部分を自分なりに作り直してみました.編集画面のスナップショット

新しいバージョンをon-sky.netに入れるとして,今のものとの整合性を何とかせにゃ.


2006-05-18

仰天

ルノーF1→ニッサン F1へと名称変更という憶測があるそうです。「将来の話」としながらもチーム代表が否定していないところがなんとも。

開発に日産側の技術者が入っていくという話なら、引っかかりは残るもののまだましかなと思いますが、単なるバッジ・ネームだと悲しい話ですね。一般的には知名度が上がるのかもしれませんが、ファン心理的にはむしろ日産に、「あなたは堕落しました」とか言いたくなりそうです。

本日のツッコミ(全3件) [ツッコミを入れる]

- mak [以前より有名な話でルノーのスタートシステムは日産の技術者が開発してます。すでに技術者交流はしてるのよね。]

- hs [なるほど。そうすると現状でも共同開発状態みたいなもんか。 いずれにせよNISSANのバッジをつけるなら、それなりの..]

- taru-k [アロンソの後釜に本山を使うしかない.]


2008-05-18

CATV 録画機能付セットトップボックス(Panasonic TZ-DCH2810)感想

加入しているCATVで月+1,000円で利用可能になったので、しばらく使ってみた感想など。

接続と画質

まずは工事当日の話から。前のSTBはD1端子でデッキに接続していたんですが、同じように接続しても映らない。工事のあんちゃんはD1には非対応とかいってさっさとあきらめ、「えー」となるも、マニュアルを読んでD端子の出力をD1に変更して繋ぎなおすとちゃんと映りました。見比べた感想としては、D1でははっきり読めるメニューの文字がアナログではちょっとつぶれる感じ。

あと、1個しかないD端子が、録画機器ではなくテレビ出力の方に割り当てられてるのはちょっと納得いかないんですが、時代の流れというやつでしょうか。

チャンネル設定

地上デジタル、BS、CATVの3放送について、12チャンネル×3ページの36局の番組を「お好み」として登録でき、そのうち1ページ目がリモコンでチャンネルボタンを押したときに選曲されます。2ページ目、3ページ目はリモコンの蓋の下に隠れている「お好み選局」ボタンを押さないと選べないようになっていて、一見無意味ですが、番組表画面で重要な意味を持つのでちゃんと登録。

番組表

表示するチャンネルを「お好み」、「テレビ」、「ラジオ/データ」、「すべて」の4つから選べます。ここで「お好み」を選ぶと、先ほど設定した各放送最大36局分だけの番組表が登録順に表示されるようになるので、うまく並べてやるとかなり便利。1画面に表示するチャンネル数は3,5,7,9と選べるんですが、7とか9では文字数の関係でタイトルがわからないので使えるのは5ぐらいまで。あとは、番組のジャンル検索がなかなか使えて○。一方で、番組表をスクロールさせる際、ボタンを長押しすると勝手にスキップモード(?)になってバンバン飛ばされるのは個人的には×。

録画予約

「探して毎回」という、その名のとおり、同じ番組を探して毎回録画するという機能についていくつかのパターンで実験。まず、F1やラリーのような不定期番組。これはぜんぜん駄目。フリー走行や予選を毎回設定すると、日曜や翌週の再放送まで録画しようとした挙句、次戦は探しきれない。(再)付きは飛ばすとか工夫のほしいところ。次に毎週定期的にある番組。これは問題なし。なんかスペースコブラの再放送をやってるのを発見して思わず登録して視聴継続。最後に同じ話が週に数回放送されるパターンとして、アニメでテスト。当然同じ回をバンバン録画。これも話数とかで判定するか、探す条件を1日1回だけでなく、毎週同じ曜日だけとかに設定できるようにしてほしかった。

あと、録画予約の際、録画先としてHDDと外部出力の組み合わせが選択できるんですが、外部出力の設定をした予約が重なると、2番組同時録画ができなくなるという挙動で悲しい思いをしました。わかりにくいかもしれませんが、HDD+HDDや、HDD+(HDD&外部)という組み合わせはOKだけど、(HDD&外部)+(HDD&外部)という組み合わせだと、後からの予約が外部出力されないだけでなく、HDDにも録画されない。外部出力は1つなので、その信号がどちらか一方になるのはしょうがないんですが、HDDには録画して欲しかった。

おすすめ番組機能

ようは学習機能なんですが、学習の条件に「番組の視聴」が含まれているため、電源をつけっぱなしにしていると誤学習しまくりで使い物にならない。できれば録画予約した番組だけを学習対象とするような設定が欲しかった。あと、おすすめマークのついた番組に対する除外学習もできるんですが、これの効力がいまいちわからない上、いったんメニューを消して、再表示させないと反映されないという挙動はいまいち。

外部録画

まずは連動録画についてですが、うちのRD-X3にはi.Linkなんてモダンなものは付いていないので、Irシステムを試すも玉砕。録画用ビデオ出力に予約した番組だけ出力するというモードがあれば、RD側の入力自動録画機能を使えるんですが、それもないので結局RDでも予約が必要という状況は変わらず。

次に、HDDに録画したものを再生しつつダビング。アナログ信号でもできない_| ̄|○ 説明書には「VHSビデオデッキなどのアナログ録画機器での録画はこれまでどおり可能です」とあるんですが、アナログ出力にはコピーガード信号のっけてません、という意味ではないらしい。要するにHDD録画したものをディスクに焼きたければごたごた言わずにDigaを買えということですか。このへんの各メーカの囲い込み戦略は最近露骨過ぎて嫌ですね。テレビや録画機器なんて、それこそメーカごとに得手不得手や癖があってそろえるなんて考えられないんですが、そういう人は少なくなったのかな。

まとめ

とまあいろいろと細かな不満はあるものの、録画のしきい値が下がったのは確実で、ラリーの速報とかダーツの試合とかスーパーアグリ広報室(次週最終回ですね)とかゲームセンターCXあたりを録画して、ちょっとした空き時間に見られるようにはなったので、月+1000円ならじゅうぶん満足といったところです。


2011-05-18

PPID(Private Personal Identifier)方式のもとでRP間での名寄せを自動化する方法

このエントリは高木浩光さんの「富士通総研が研究員のコラムを削除、国民ID・共通番号制度を巡る現況」を読んで、PPID方式に対する誤解が広まるんじゃないかと勝手に心配して書いたエントリです。まず断っておくと、Webサービスで使われるPPID方式と情報連携基盤とではそもそも仕組みが全く違いますので、このエントリに書く名寄せの方法は情報連携基盤では使えません。従って、本エントリは高木さんの主張に何ら影響を与えませんし、私自身『フラットモデル』は論外という立場です。

RPの結託による名寄せの仕組み

さて、高木さんはLiberty Allienceの目的として、

*RP同士が結託してもIDによる名寄せができないようにする

と書かれていますが、PPID方式であってもRPが結託した場合、それらRP間で共通する利用者については機械的に名寄せが可能、ということを示したのが右の図になります。

図の上半分は前提となる部分で、IdP上でのID:xxxxのユーザに対して、RP1ではID:zzzzが、RP2ではID:yyyyが割り振られている様子を表しています。図の一番下にいるのが、今回の例で運悪く名寄せの対象となるID:xxxx@IdPの利用者です。この時、RP1とRP2が結託してシステムを構築し、図の下半分の流れとなるように仕組みます。

  1. ユーザがRP1にログインする
  2. ユーザが利用しているブラウザに対して永続的なCookieでRP1上のid:zzzzを保存させる
  3. ユーザがRP2にログインする
  4. 適当なタイミングでRP2のid:yyyyという情報を含むWebバグをページに埋め込んで、5.のアクセスを誘発させる
  5. 2.でCookieとして仕込んだRP1上でのIDと、5.のリクエストに含まれるRP2上でのIDを紐付けする。この時点でRP1上では自サイトのzzzzと、RP2のyyyyの名寄せが完了する。
  6. (おまけ)RP2にお礼として、RP1で紐付けられたIDのペアを渡す。

あとはこの仕組みを適当にカモフラージュして運用を続ければ、RP1-RP2間の名寄せは自動化できます。 したがって、PPID方式では

* RPのIDからIdPのIDを逆計算する
* RPがIdPのデータだけ{{fn 'RPにPPIDを振り出すための「種(salt)」は取られていないということ'}}を取ってきて、自分のデータとIDで名寄せする
* RPが他のRPのデータを取ってきて、自分のデータとIDで名寄せする
* 複数のRPからデータを取ってきて、それらをIDで名寄せする

といったことはできませんが、

* RPどうしが悪意を持って結託して、お互いのIDを名寄せする

というのを防ぐのは残念ながらできないということになります。

余談ながら、この方法はWeb広告やGoogle analyticsで使われているやり方のアレンジで、いってしまえば一般的に広く利用されている仕掛けの応用ですので、PPID方式自体の欠陥という訳ではありません。つまり、これを欠陥あるいはセキュリティ上の脅威として防ごうと思ったら、Web広告やGoogle analyticsも使えなくなるようにブラウザの仕様を変えるしかありません。

情報連携基盤でこの方法が使えない理由

PPID方式にこのような抜け穴があるなら、情報連携基盤にも同様の穴があるのではないかと考えるのは当然ですが、すばらしいことに情報連携基盤ではそのようなことが無いようにちゃんと設計されています。

個人情報保護ワーキンググループ個人情報保護WG(第3回)議事次第(資料2−2)番号制度 番号連携イメージに(ちょっとごちゃごちゃしていてわかりにくいですが)ある通り、情報連携基盤の利用において「利用者」は必ず「マイ・ポータル」および「情報連携基盤」経由で各「情報保有機関」にアクセスするような仕組みとなっています。図では「情報連携基盤」と「情報保有機関」を結ぶ専用回線を使った閉域ネットワーク内における連携でPPID方式を使うという事になっており、私が最初に示した図に当てはめられるような「情報保有機関」が直接「利用者」にサービスを提供する仕組みではありません。このため、「情報保有機関」にCookieやWebバグを仕込む余地は無く、一般的なPPID方式にある名寄せの危険性は情報連携基盤の現在の設計には無い、ということになります。

逆に言うと、「なぜマイ・ポータルなんてお仕着せのものを使う必要があるんだ、情報保有機関が直接サービスを提供すれば良いじゃないか」とか、官民問わず「情報連携基盤をWebサービスのIdPとして解放しろ」などという方向に向かうと危険ということになります。

一般的なPPID方式でのRPの結託のリスクは?

ここで情報連携基盤から離れて、一般的なPPID方式のWebサービスにおけるRP結託のリスクについてちょっと補足します。

最初に書いた通り、PPID方式でもRPどうしが結託した場合に名寄せは防げませんが、名寄せ可能な範囲はあくまで結託したRP間のデータのみで、IdPや、結託の枠外のRPのデータまで名寄せされることはありません。従って、こうした名寄せのリスクの大きさは、結託の規模によるといえます。

まあ、世の中にはすでにRPどころか、IdPも含めて結託して、名寄せ・マーケティングに利用しますと宣言しているシングルサインオンサービスもすでにありますが。楽天とか楽天とか!楽天とか!!楽天とか!!!

フラットモデル vs. リンクコード方式へのコメント

もうちょっとだけ続きます。うまくまとめられずに箇条書きで逃げている上に同じことを何度か書いたりしてますが、ご容赦を。

  • フラットモデルでは「名寄せ」に作業不要
    • 右の図(上)で言えば、年金RP、医療RPからそれぞれ表を入手するだけで、互いのデータを紐付けできてしまう(1980.5-1981.3まで年金未納の人間が2005年の8月3日に内科で診療を受けている、とか)
    • PPID方式では、表を入手しただけでは、情報連携基盤および各情報保有機関のリンクコードどうしの紐付け(yyyy1 = zzzz3 (= xxxx2))はできない
  • 「(国民)番号」ベースのフラットモデルはさらに論外
    • 右の図(上)でxxxx1,xxx2,...が「(国民)番号」状態
    • 「(国民)番号」と個人情報の紐付け情報は「情報連携基盤」外からも入手できる可能性がある。逆説的に情報漏えい時の影響範囲が「情報連携基盤」の外にまで広がってしまう。
  • 漏えいしたときの影響に差が無い?
    • 「漏洩が起きたらそもそも駄目」というのは失礼ながら「安全神話」に通じる危険な思想に見える。漏えいは起きるものだと想定しての設計が今どきなのでは?というわけで以下その前提で。
    • フラットモデルでは、複数の情報保有機関から漏えいした時のIDベースの名寄せが簡単。例えば、年金RPで漏えいが起きた時、医療RPでさらに漏えいした場合のインパクトが大きくなる。そういう意味で漏えい時の影響範囲は情報連携基盤の枠組み全体に及ぶ。
    • そうした状況になってしまった場合に、フラットモデルでIDコードをリセットしようとすると、IdPや医療RPにまで影響してトータルで膨大なコスト負担が必要となる。
    • PPID方式では、年金RPで漏えいが起きた時に年金RPにおけるリンクコードだけをリセットできる。リンクコードを「見えない」コードにしておく利点はここにもある。
  • フラットモデルでPPID方式と同等の安全性を確保することは不可能
    • 「リンクコード」を生成するための「種」をIdPが握っていて、RPだけでは「リンクコード」を再現できない点が重要
    • RPで「IDコード」を「種付きハッシュ」化しても、「手提げ金庫の底にセロテープで鍵」状態になってしまい、種ごと盗まれたらおしまい。
  • 【余談】政治面とかパフォーマンスとか度外視するなら各情報保有機関に「個人情報」は持たせない設計がより理想的
    • 具体的には
      • 氏名・住所等の「個人情報」は情報連携基盤側で管理する。あるいは、「個人情報」専用の情報保有機関を作って情報連携基盤で中継する
      • 各情報保有機関にはリンクコードと各機関固有の情報との対応表だけを保存・管理させる
      • 情報連携基盤上で各情報保有機関のデータと「個人情報」をマージしてマイ・ポータルに渡す
    • メリット
      • 各情報保有機関が「個人情報」込みでデータを参照するときには、必ず情報連携基盤にリクエストしなければならなくなるので、「アクセスログ」を情報連携基盤で取れるようになる
      • 各情報保有機関のDBに保管されている情報だけでは完全に個人を特定出来なくなるので、PPID方式の優位性がより際立つ。

まとめ

* 一般論としてRP(IdP)に結託してWebバグやCookieを使われたら名寄せは防ぎようがない
* PPID方式では「RPどうしが結託しても名寄せできない」とは言い切れず「第三者による名寄せはできない。また、あるRPが漏えい起こした時に、IdPや他のRPに迷惑をかけない」ぐらいまで
* それでもPPID方式とフラットモデルとの間には越えられない壁がある