Google ストリートビューが「ダメ」な理由 : あんたらは準備の出来ていないWindowsマシンをネットに強制的に晒すのか?

少し前に、Googleのストリートビューが公開されました。
[紹介記事 on Internet Watch]

米国での公開時から違和感を感じていたけれど、最近やっと上手い言い方にたどり着いたので某所にも書いたけどこちらにも書いておく。

ストリートビューは便利だし、面白い。これが無くなることはなく、発展していくでしょう。

彼らの理論では「家なんてダレからでも見られるんだから、元々公開してあったじゃん」となっているけれど、これは違う。そこには「物理的ファイアーウォール(FW)が有る」んです。簡単に言うと、空間FWと手間FWです。

京都の下町の一角なんて、世界中の人から見られるなんてことはないし、日本中からということもない。京都の人なら何とかなるけど、それでもわざわざ見に来ようとする人なんていないし、見に来るのにもそれなりの費用がかかる。これが空間FWです。

ネットワークに照らし合わせれば、プライベートネットに当たるわけで、そこにあるノード(家)もそれを踏まえた状態(低セキュリティ状態)にあるわけです。当然、世界中の人から見られる準備なんてされていません。逆に、元々ある程度に人に見られる前提の商店街など(DMZ相当)は、それなりの状態になっています。

つまり、ストリートビューが行ったことをネットワークに当てはめると「プライベートネットワーク内に無防備のWindows端末が有ったときに、端末の管理者に一切通知すること無く、強制的に外部ファイアーウォールを撤去してインターネットに晒す」ことに等しい。
(本当は、晒されたことに気づかない人、気づいても対処できない人が多いのでなお悪い)

たとえ、それで便利になるとしても、これが非常によろしくないことは、多くの人、Googleの中の人も理解しているはずです。便利になるから移行するとしても、ちゃんと通知して、緩やかに移行できるようにするべきです。ストリートビューは法的・技術的には問題有りません、が、公開までの手順が「倫理的に」破綻しています。

物理世界はネット世界と違って、コマンド数行で状態を変えることが出来ません。例えば「道から見える窓を無くす」といったことを行うにも多大な労力と時間がかかります。ネット世界のことを、単純に物理世界に当てはめないで下さい。物理世界の変化は非常に遅く「対処しろ」といわれてもすぐには対応できません。

おそらく将来的には、これらがリアルタイム更新になって、時間FWも外されるでしょう。そのときはもっと上手く対処していただけるようにお願いいたします。

Ubuntu dapper → hardy をやってみた

LTS to LTS で upgrade を敢行。

いくつか躓いたところがあったので、それについてメモしておきます。

まずは基本動作、source.list の書き換え後に sudo aptitude dist-upgrade (apt-get ではなくaptitude を使いましょう)。

- - - - - - - - - -
躓いた所その1

dpkg: regarding .../dmsetup_2%3a1.02.20-2ubuntu2_i386.deb containing dmsetup:
dmsetup breaks udev (<< 113-0ubuntu1)
udev (version 079-0ubuntu35) is present and installed.
dpkg: error processing /var/cache/apt/archives/dmsetup_2%3a1.02.20-2ubuntu2_i386.deb (--unpack):
installing dmsetup would break udev, and deconfiguration is not permitted (--auto-deconfigure might help)
Errors were encountered while processing: /var/cache/apt/archives/dmsetup_2%3a1.02.20-2ubuntu2_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

どうやら、古い udev が悪さをしているらしい。
こちらのページでは「apt-get remove udev をするとぶっ壊れた」とのことでしたが、aptitude で remove をしたところ、古いのが消されて、新しいのがインストールされました。良かった良かった。
# sudo aptitude remove udev

- - - - - - - - - -
躓いた所その2

なにやら、以下のメッセージが /ver/log/messages にいっぱい。
device-mapper: ioctl: error adding target to table

こちらのページを参考に evms を削除する方向で対応。
# sudo aptitude purge evms

- - - - - - - - - -
躓いた所その3

perl を実行するごとに、以下のメッセージが出てくる。
perl: warning: Please check that your locale settings

locates が壊れてました。これは aptitude 側でやって欲しいなぁ。
以下のコマンドで対処。
# sudo dpkg-reconfigure locales

- - - - - - - - - -
躓いた所その4

nfs のマウントオプションが変わっていました。
grpid が無効になっていましたので、それを削除しました。

- - - - - - - - - -
ひとまず、こんな所でしょうか。
まぁ、dist-upgrade がさっくり終わることはないですよねぇ。

[バグ] Apple製 Bonjour SDK for java の TXTRecord がバグってる件

Appleのstable版として落とせるBonjour SDK Java 版の TXTRecord クラスのレコード長計算関連がバグってます。

症状としては、最大長255 bytes(これもおかしくて本当は200のはず)まで入れられるはずのTXTレコードに、127文字までしか入れられない。

原因は、レコード長を byte 型で扱っていること。
Java のbyte 型は、-128~127 の符号有り型なのだけど、どうやら符号無しの方法でコーディングされています。なので、128以上を入れてしまうと、長さがマイナス値を取り、byte配列各保持にマイナスの大きさの配列を確保しようとして落ちます。

運が良いことに、TXTRecordクラスはfinal じゃないので、サブクラスを作って、長さ保持変数をint にしたり、byte から長さを取るところを byte[num] & 0xFF にしたりして対応しました。

今は時間が無くて無理だし、まさかCVS版に残っているとも思えないけれど、もし残っているようならレポートしておこうかな。

1日必要カロリー & 適性摂取量 計算機

ダイエットシリーズ
その他

- - - - - - - - - - - -
毎回計算するのが面倒だったので、生活活動強度に応じた必要カロリー&適性摂取量の計算機を作ってみました。

数値は、生活強度別エネルギー所要量表(kcal/日)から取ってきました。
一時出典は「最新食品標準成分表五訂版」社)全国調理師養成施設協会」とのことです。

糖質(炭水化物)は必要カロリーの0.7掛け、タンパク質は体重×1.1 で計算、脂質は残り物として計算しています。

生活強度の目安としては、ずっと家にいる人は1、 研究者やSE等で2、立ち仕事が多ければ3、重労働は4、と言ったところです。
詳細については、香川大学の医学部 保健師の健康教室にもっと詳しくてわかりやすい一覧がありますのでそちらをご覧ください。

1,2,3,4
18-29,30-49,50-69,70-
男,女
kg

- - - - - - - - - - - - - -
1日目安
: kcal
: g
: g
: g



と思ったら、動かない・・・。う~~ん。Bloggerでjavascriptは何かと面倒だなぁ。
原因判明。onclick=""だったのが原因だった。javascriptで""使ってるから''じゃないとだめっすね。

追記: なんで18歳未満がないかというと、どうやら体重対タンパク質の計算値が1.1じゃないらしいのだけど、適正値が見あたらなかったためです。もしご存じでしたら教えてください。よろしくお願いします。

Blogger で javascript (続) < > ってどう使うんだ?

onclickに仕込む場合、途中に<>があると投稿できないようです。

&gt;なんかで代用がきくのかな?

以下はそのテスト。



結論
どうやらOKらしい。

Blogger で javascript を投稿するには

Bloggerでjavascriptが投稿しづらい!!

今のところ見つけている方法は二つ。
一つは、onclick="func(); function func(){......." として、タグに埋め込むこと。
ただ、その場合は改行等しないで、見づらいコードをずらずらと書くことになる。
もっとも、Bloggerは普通のタグを使うにも、改行時に勝手に<br>を入れてくれるので綺麗に書けないのだけれど・・・。



他の方法としては、テンプレートにAdding javascript to Blogger postsで示されているコードを入れてしまう方法があるという。

ということで、以下はテスト。
# だったのだけれど、どうもダメっぽい・・・。

[訂正] Java SunJCEのRSA暗号時のパディングはおかしくなかった

どうやらおかしくなかったらしい。

private key で暗号化した場合のパディングが、以下のようになるらしい。

01 FF{8} FF* 00 bytes(INPUT)

public key で暗号化した場合、普通にPKCS1 のパディングが使われていました。

ただ、頭の0x00が抜けていましたけれど。
これって飛ばしておいて良いのかな・・・。

ちなみに、Privateのときに使われていたのは、EMSA-PKCS1-v1_5-ENCODEっぽい?
こちらも頭の0x00が抜けていましたけれど。

巨大数値化した時点で、頭の0x00は無くなることから、これはこれで良さそうだ。
だとすると、注意しないといけないのは、復号プログラムを書くときに、先頭の0x00が無くても慌てないことなのか。