it: 2004年1月アーカイブ

Polifonia Caffe'(2004-01-27)#p01

はっ!!これはまさしく7行プログラミング。

7行プログラミングといえば2ちゃんねる、プログラム板にありましたな…まだあったのか…^^;。
お、作成者を発見。
7 line programming
素晴らしき職人芸ですねぇ^^;。

他にも7行プログラミングで検索すると職人さんはたくさんいらっしゃることが分かります。

昔は一画面プログラムなんていうのをよく作ったものです^^;。
(プログラム全体が80文字*25行の画面に収まるように作るの。当時は BASIC)

その文化から生まれたお遊びなんですよね。

(追記)
こんなのもあります。
Wiki/7wiki - 『7行で書くWiki』 う~んすごい

トップページなのでしばらくしたら消えると思うけど…。
(追記)現在はこちらにあります。

[ASK ACCS TOP]

(2) ASKACCSは、必要と認められる以上の個人情報を入力させていたと考えられる。
 ASKACCSは、不特定の第三者から広く質問を受け付け、それに回答することを目的としていた以上、回答を送付するために必要な最低限の個人情報(メールアドレス等)の入力を求めることはやむを得ないと考える。
 しかし、ASKACCSの質問フォームでは、さらに住所・氏名等の個人情報の入力まで要求していたところ、このような情報まで必要であったとは認めがたい。
 個人情報を扱う際には、その管理に万全を尽くすことはもちろんであるが、それと同時に、そもそも不必要な個人情報は取得しないことも求められているというべきである。

すばらしい。これ、もっと騒いでおくれ。

それにしてもこの「不要な個人情報まで入力させる」ことも、ファーストサーバの提供した CGI がそうなっていたから、では無いのかなぁ…(知らんけど)。
問題の根本はレンタルサーバが用意していた CGI にあるわけで、サービス提供者だけでなく、CGI 作成者にもそういった機能の実装に細心の注意を払うことが広く啓蒙されればいいなぁ。

セキュリティ専門家が電子投票システムに「ダメ出し」 - CNET Japan

選挙のような投票を、不正を防止し、且つ投票者の安全を保ちつつ、インターネット越しに行うことは不可能という話。
当たり前な結論だけど、今やっている紙を使った投票だって万全じゃないわけで、リスクの差、つまり程度問題なのよね。この人たちは必死に無謀な挑戦を試みてこういう結論に至ったわけで、具体的に決定的な問題が何だったのかはしらないけれど興味深いです。誰か原本確認してついでに和訳して^^;;

電子投票と言えば「スラッシュドット ジャパン | 信頼できる電子投票はどうすれば実現できる?」というのがあり、大概のことは語られている気がします。
その中でも、この記事がこの問題の難しさを端的に語ってくださっています。(ほとんどまるまるの引用(?)^^;)


シュナイアー「暗号技術大全」 [sbpnet.jp]に、電子投票プロトコルの要件が列挙されています(一部省略して引用):

1.有権者しか投票できない
2.みんな2回以上は投票できない
3.ほかのだれかがだれに投票したかは、誰にもわからない
4.だれも他人の票を複製できない
5.だれも見つからずに他人の票を書き換えられない
6.すべての投票者は、自分の票が最終的な評決で考慮されたことを確認できる

個人的には4.辺りは要件としては一番希薄な存在だと思うのですが、実はこれが一番難しいそうです。1,2,5は解決できるプロトコルがあるようです。個人的には、3が一番難しいんじゃないかと思います(後ろで上司が投票している姿を確認する、という問題)。何かしらの専用機器で解決する問題かな、という気は何となくしますが、具体的な物品を考えたことはありません(でした)。

私は「誰が投票したか」に関しては、投票したという事実を管理する組織を信頼するしかないかなと思っていますが、「誰に投票したか」についてはチケットとしてワンタイムなキーペア(PKI 用語)を発行し、投票内容を集計人の公開キーで暗号化したものにワンタイムなキーペアの秘密キーで署名する、というのが思いつきます。

チケットはカードにでも突っ込んで配布し、有権者データベースにはチケットの公開キーのみが入る、と。

そうすると、

1.チケットが無いと投票できない
2.同じ秘密キーで署名されていたら二重投票が判明する(署名検証しないと判らないのが辛いな)
3.集計人以外にはわからない
4.複製は可能だが二重投票が出来ないのでOK
5.書換は署名により不可能
6.自分の署名した情報の存在を確認可能

と…なるか…?あんまりちゃんと考えてないので抜けあると思われ^^;。
抜けが無かったら「不可能」という結論になるはず無いしねぇ。
一番に思いつくのは集計人が信頼できるか?だもんなぁ。
集計段階では署名を取り除いた票の集合だけにして、複数人の目の中で開票作業を行うというのが考えられるけど、署名を取り除いた瞬間に脆弱になるしなぁ-_-。乱数IDも併用して何とかならんかなぁとか思いは馳せてみたりするけんども。
カード制作会社は信用出来るんかいな…。
投票所にあるであろうカードリーダも同じく…。


あぅ、技術ネタは別の日記でしようと思ってたんだけど、CNET へのトラックバックのテストも兼ねて~^^;。

ARTIFACT -人工事実- | サイトの読者を減らす努力と「儀礼的無関心」

Web と言えば誰にでも見られるのが当たり前だけど、「沢山の人に見られるのは嫌だ、けどぽつぽつはお初さんも来てほしい」という人もいるわけですね。ふむふむ。
そのように考える動機としては、単に恥ずかしい、ということ以外にも、半ば独り言か公園談義のつもりで書いてたのに知らん人からいきなり糾弾された、みたいなことが起こるのがやだ、というのもあるそうで。まぁ、理解できます。

「誰でも見れる」場でもしとんでもな主張/誤った説明をしていたら、それを見て誤解してしまう人を増やさないためにも反論/指摘がなされる必要性はあるんですが、そもそも「誰にでも見てほしくなんてないし自分の主張を世間が認めろなんて思ってないよ」という立場だとしたら余計なお世話。でもアクセス制御を入れるのは導入側もユーザ側も面倒、と。

全個人がユニークID(電子証明書)でも保有するようになれば「あなたは私のページを見てもいいよ」とする行為が簡単になるんでしょうけどね:p。あ、簡単なパスワードでもこの程度の目的になら別にいいか。
でも、新規流入者の閲覧も許可しつつある程度制限されてほしいわけだから、非許可ユーザによる週単位の最大アクセス数を指定できる、なんてのもありかもなぁ^^;。

それはそうと、ココログなんかは「沢山の人に見られる」なんて知りもしない方の比率が他の日記系より多そうだなぁ。
# 某高校生とか、きっとそうだろうなぁ:p

(追記)
このネタ、割と興味を持っている人がいらっしゃるようで、なら、こういうの作ればいいのに、と。
apacheモジュールとか servlet filter として以下のような plug-in を作る。

  • サイトにキーワード(パスワードと等価だが秘匿性のゆるいもの)を設定可能。変更も容易なUIとする。

  • キーワードを知らない人からの一定期間内アクセス可能数を設定可能。

  • 当該サイトへのアクセスはキーワードを含む cookie が送られた場合は無条件に through。

  • 設定したキーワードが cookie に書かれていないアクセス数はカウントしておき、「一定期間内アクセス可能数」を越えた場合はキーワード入力画面へ飛ばす。

  • キーワードが送られたらそれを cookie にセットする。

これで初見さんアクセスをある程度制限しつつ、知人は自由にアクセスできる Web ページの出来上がり。
BASIC 認証のように毎回認証ダイアログが出ることも無い、と。ココログなんかの場合はちょっとした拡張で入れられる機能だ。# 負荷は上がるけど
作れば話題になるかなと思ったのでやろうかとも思ったけど、別にいいや^^;。

(さらに追記:2004/02/05)
上記のような形態であれば、既存の任意のシステムに組み入れ易いと思うわけです。
だから、ホスティングのユーザなどには上記の設定 UI だけが管理画面上に見えるように出来ますし、インストールも「このモジュールを使う」という設定をちょろっと書くだけで済むのではないかなぁ、というつもりでした。
あんまり見られたくない人を大事にしたいっ!!という方、或いは話題になりたいという方^^;、是非どうぞ~。

「問題解決力」を高める思考スキル(1)
(現在第5回まであります。http://jibun.atmarkit.co.jp/lskill01/index.html から辿れます。)

これは非常によさげな連載。おいらがここで言わんとしていること(※)をちゃんと裏づけ/説得力ある形で^^;語ってくれています。

※これから言おうとしていたこともあるのでネタ損もあるけど-_-。もちろん考えてもいなかったような視点もあった。

はたから見ていて目的を見誤っている/見えていないことは本当に多い。自分も与太に流れて議論/思考を発散させることはよくあるけど、おおもとの目的は忘れないように気をつけてはいるつもり。でもちゃんと読んでもっかい頭にたたき込みなおすのに最適な記事でした。
特に「論理展開」については自分が全く下手くそと思っているところなのでよーく勉強しておかねば^^;;。
# …ってか、やっぱり本読まなきゃなぁ…と思うよ…-_-。

IT関係の記事ということになっているけど他業種はおろか日常生活でも役に立ちます。
是非みんなが意識して欲しい内容〜。

ところで第3回にある「論理展開における6つの“落とし穴”」ですが、これはまさしく詭弁というやつですな。詭弁は大抵確信犯なので厄介ですが、自分も含めて大抵の人間は自分の考えにバイアスを置いてしまう物なので気付かないうちに詭弁をふるっていたりするのね-_-。気をつけましょう〜。
ついでに、前においらが感心したリストをリンク。オリジナルは 2ch のコピペで誰が書いたかも不明ですが。いつの間にか項目が増殖してるや^^;;。笑える上に感心できるのではないかと。

PukiWiki - 詭弁の見抜き方

遅まきながら、朝日新聞の"「ネットの脆弱さに警鐘」国立大研究員が個人情報を公表" についてのコメント。
# 朝日新聞取ってたから朝刊の一面に載っててさすがに目についてはいた^^;。

スラッシュドット ジャパン | 欠陥を指摘するはずが個人情報流出。セキュリティ専門家に捜査の手

やその他いくつかのソースもざっと見た上での感想。

くまの世界観測: 朝日新聞 個人情報漏洩報道の謎
では、

なぜこのタイミングで朝日新聞では1面記事として大きく取り上げたのか。そしてことさら「不正アクセス禁止法違反の可能性」を強調するのはなぜでしょうか。

とされている。確かに変な方向にバイアスが掛かっているようにも見えそうではあるし、背景を知らない人が読んだら、「あぁハッカーって恐いな」みたいな明後日の方向への理解を助長しそう-_-。
# あるいは「office 潰しだ」なんて意見もあって、その可能性も十分あるなと思えたし。
けど、この記事自体はあくまで office 氏が行った、他所の管理する個人情報を特定多数に開示したという行為についての記事、と考えると、この記事自体はおかしな事は書いてないのよね。

さて、スラッシュドットでは、これを糧にしてのダメダメベンダへの脆弱性報告の仕方について議論されてたんだけど、このコメントが良かったです。
トラブルの種は「相手に義務があると思ったり、自分に権利があると思ったりする」ことである、と。
なるほどー。逆を意識できればいいのよねー。>「相手の権利/自分の義務」
報告はすればいいけど、見返りを要求しだすといろいろありますなぁ。

ところで、このページを読む人はセキュリティとか詳しくない人が多いし、このページ自体にミスリードされてもやなので念の為に書くと、web サイトの欠陥はかなりの割合で存在します。
特に個人情報の漏洩については、漏洩が起こっていてもサイト自身が気付いていなかったり、気付いてもユーザには知らせないような所が多いと考えたほうがよいです。特に個人情報の入力をやたら求めるサイトは信用しないほうがいいです。個人情報保護ポリシーと何のために利用するかをちゃんと明記してくれてないと怪しい。
# あぁ、書いておくべきことがどんどん膨らむけどボリュームが大きくなるのでこのへんで_o_。

今回の報道タイミングの裏側はわかりませが、何よりも欠陥の指摘をするのは「悪いハッカー」という程度にしか報道できない朝日新聞の執筆水準でしょう。
こちらはそのとおりですね:)。「指摘/公表の仕方がまずかった人がいた」というだけの話なのにね。ACCS の問題自体も大きく報道した上で今回の記事があれば判るけど、そっちは他所は報道してたのに朝日だけは報道してなかったらしいし。 # 朝日はやめようと思う:p。

報道タイミングについては、office 氏の行動に関して警察が動きだしたから、と誰かが推測していました。まぁ、11月に報道された時とは状況が変わったんでしょう。

一応>academic office(office 氏の web ページ)
ついでに高木さんの日記にもリンクしとこう:p

このアーカイブについて

このページには、2004年1月以降に書かれたブログ記事のうちitカテゴリに属しているものが含まれています。

前のアーカイブはit: 2003年12月です。

次のアーカイブはit: 2004年2月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。