初めまして．いつも解説記事を楽しく読ませていただいております．

SSDに複製を作られたとの事ですが，こちらはバックアップ用でしょうか．
ご存じかも知れませんが，フラッシュメモリはリフレッシュせずに長期間経過すると，データが消失してしまいます．
http://pc.nikkeibp.co.jp/article/basic/20091109/1020302/ (少し古い記事ですが)
SSDは書込みの際に適宜リフレッシュされるようですが，読み込み専用で使うと通電していてもリフレッシュされないので揮発してしまうのだとか……．

装置の寿命がかなり長いようですので，保管用途には光学メディアかHDDの方が安心かと思います．

推測しなくても，MUFGとSMBCのサイトに「乱数表の数字」「暗証カード」と書かれていましたね．
http://www.bk.mufg.jp/info/phishing/ransuu.html
http://www.smbc.co.jp/security/popup.html

# ああ，アホなことをIDで書いてしまって恥ずかしい．
## しかも，後半不要だったし．

> 通常の画面での入出力をジャックするだけじゃ不足な情報があるから、
> 専用の入力でそれを収集したい、とか、そういうことなのかな？

資金を移動するために，二要素認証 (乱数表とか) の情報を入力させたいのではないでしょうか．
攻撃者としては乱数表を全部入力させるのが理想ですが，怪しまれるでしょうし，セキュアトークンには対応できません．

ID/パスワードの情報は盗聴で得られる (あるいはセッションを乗っ取ればいい) から，バックグラウンドで振り込みの取り引きを進めることは可能です．
振り込みの最後の認証操作 (乱数表の一部を入力するとか，セキュアトークンに表示された文字列を入力するとか) だけを利用者にやらせれば，資金を攻撃者の好きなように動かせますね．

ヒートシンク(放熱フィン)全体にできるだけ小さな温度勾配で熱を移動させることが肝要なわけで. それを実現するためにヒートパイプを使ったり, 水冷で強制的に熱移送させたりしてるわけですね. ところが, 今回の技術ではそういった後処理のことを全く考慮せず, いきなり1/10とかの数字を出してくるので, 胡散臭く見えてしまいます.

technical report の12ページ目によると，フィンが小さくて済むために熱の移動距離が短く，ヒートパイプなどは必要ないそうです．

そして，その効率の高さは，(ファンを別体とせず)フィンを回転させる所から来ているようです．
薄い空気の層で熱伝導をするという発想は1つの breakthrough ではあるものの，それだけの技術ではないようですね．

technical report の11ページ目を見ると下にように書いてあるので，取り付け方向の制限は無いようです．

air-bearing cooler can be mounted in an arbitrary orientation (e.g., up-side-down, sideways,etc.)

また，同じ段落によると，HDDと違い，もし振動で円盤が接触してしまっても，円盤表面にダメージはないそうです． (よほど強い衝撃を与えた場合は分かりませんが，先に他の部分が壊れるんじゃないでしょうか．) technical report なのに(?)初心者にも読みやすく書かれていますし，小型ファンの効率の悪さに対する考察などもあって，かなり面白いです．

我家の給湯器には，

• 非常時には飲用水として使え
• タンク下部の緊急用蛇口を使え

と明記されていますよ。

なるほど，緊急用蛇口があるのですね． 管理したことのあるもの (マンション用のものや，シンク内に設置する小型のもの) には無かったので，知りませんでした．

給湯器のお湯が飲用に適さないのならば，ものすごく不便では? やかんに給湯器経由のお湯を入れるな，という話ですよね。

という話です．私の見たことのある物には，説明書に明記されていました．

例えば，エコウィル 飲用で検索すると，飲用には適さないという情報がたくさん引っ掛かります．

(本当に危険度が高いなら，台所の蛇口から出せませんから，それほど神経質になる必要はありませんが)

今まで見たことのある貯湯式の給湯機は，全て飲用禁止となっていました．
容器に高温で保存されているので，タンクからいろいろと(金属イオンなどが?)溶け出しているんじゃないでしょうか．
非常用の数日分なら水が無いよりもはるかに良いでしょうが，長期間の飲用は危険だと思われます．

# それ以前の問題として，上水道の水圧が無くなってもタンクからお湯が出せますか?

Google CGI API for Japanese Inputを使っているそうなので，入力した内容が Google に筒抜けになってしまいます．個人的には，誤ってパスワードなどを入力してしまう可能性を考えると，使用する気にはなれません．

また，確認していませんが，もし平文通信で同 API を使用しているとすると，経路上で入力内容を盗聴することが出来てしまいます．同 API は HTTPS でも使用できるようですので，こちらを使用していれば問題ないのですが．

なお，ローカルにインストールして使用するGoogle 日本語入力では，「入力した文字や文章がGoogle に送信されることはありません」と明言されています．

> 既にGPLとして公開してしまったコードをプロプラにすることは利用者との合意の一方的な破棄だからダメなんだろ？

違います．「GPLで提供した契約」を破棄できないと書いてあるだけです．

> その引用したコメントに既に書いてるじゃないの。

私は一文字も引用していませんよ．

ところで，私が書いた以下の二行は理解してもらえましたか?

> ソフトウェアライセンスというのは，ソフトウェアプロダクトの提供者と被提供者の間で取り交わされる契約です．
> 提供者は，自身が持つ権利の範囲内ならば，どのような条件で被提供者と契約しても構いませんし，被提供者によって契約の内容を変えても構いません．

他のコメントで既に述べられていますが，噛み砕いて説明します．

> ＞プロプラにするときに別にローカル変数の名前を変える必要さえありません。
> ＞GPLのコードと全く同一であってもいいのです。
>
> これはさすがにおかしすぎるだろ。

おかしくありません．

ソフトウェアライセンスというのは，ソフトウェアプロダクトの提供者と被提供者の間で取り交わされる契約です．
提供者は，自身が持つ権利の範囲内ならば，どのような条件で被提供者と契約しても構いませんし，被提供者によって契約の内容を変えても構いません．

例えば，ソフトウェアプロダクトの全ての著作権を持っている人は， (法令に違反しない範囲で) 任意のライセンスでプロダクトを提供できます．
一方，GPLで提供されたプロダクト(もしくはその派生物)を保有している人は，そのプロダクトをGPLの制約の範囲内でのみ，他者に提供できます．