2010年06月21日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕[http://www.nantoka.com/~kei/diary/?20100526S2][セキュリティ][プライバシー] このエントリーをはてなブックマークに追加

容疑者とされた当人が、 Librahack[http://librahack.jp/] として、顛末を説明している。
想像通り、端的に言えば、図書館ページが提供するインターフェイスが使いにくいので、スクレイピングして、検索しやすいデータベースを用意しようとした。ということの様だ。
だとすると、 前の記事[http://www.nantoka.com/~kei/diary/?20100526S2] でも書いたけれども、こんなことで逮捕される様では、技術的な実験も研究も、全て、逮捕を覚悟して掛らなければならないということになる。結果、技術の進歩を著しく阻害する危険性がある。
こんなことが起これば、日本でGoogleの様な、あるいはGoogleを超えるサービスを開発しようとは思わなくなる。
実際、図書館の蔵書データベースを無償で提供している カーリル[http://calil.jp/] というサービスがあるが、この会社は拠点を米国に置いている。
この逮捕が、日本のネット技術の進歩を抑圧する目的で無かったのであれば、当局には、事情を説明する責任があるのではないか。
ところで、多くの図書館は、思想信条の自由を守り抜くため、 図書館の自由に関する宣言[http://www.jla.or.jp/ziyuu.htm] を掲げており、 これは 岡崎市立中央図書館[http://www.library.okazaki.aichi.jp/tosho/index.asp] も、 例外ではない[http://www.library.okazaki.aichi.jp/tosho/about/activity.html]
この宣言では、
第3 図書館は利用者の秘密を守る
1. 読者が何を読むかはその人のプライバシーに属することであり、図書館は、利用者の読書事実を外部に漏らさない。ただし、憲法第35条にもとづく令状を確認した場合は例外とする。
2. 図書館は、読書記録以外の図書館の利用事実に関しても、利用者のプライバシーを侵さない。
3. 利用者の読書事実、利用事実は、図書館が業務上知り得た秘密であって、図書館活動に従事するすべての人びとは、この秘密を守らなければならない。
ということを宣言している。つまり、正当な令状無しに利用者の利用事実の記録を外部に漏らすことは無いと言っている。「利用事実の記録」には、私は、Webサーバのアクセスログは含まれると考えるのだが、だとすると、今回の事件で、愛知県警は捜査令状を得た上で、ログファイルを押収したのだろうか。
だとすると、その中には、当然、他の利用者の検索履歴も含まれていたはずで、他の利用者に対して何の説明も行われないのはおかしいのではなかろうか。

岡崎市立図書館蔵書検索システムの謎:

岡崎市立図書館蔵書検索システムのページにアクセスしてみて、表示ができなくなったりすることを不思議に思って調べてみたのだが、このサイト、 ASPで生成しているページに関して、Cookieで多重アクセスを抑制しようとして何か謎な現象が起きている様に見える。
本件で問題になっている、 新着情報[http://www.library.okazaki.aichi.jp/tosho/Newbook/0200.asp] のページもASPページだし、 図書館のトップ[http://www.library.okazaki.aichi.jp/tosho/index.asp] も、 蔵書検索ページ[http://www.library.okazaki.aichi.jp/tosho/asp/kensaku_g.asp] も、ASPで生成されている。
なぜ、こう推察したかは、以下の様な観測に基づいている。
何らかの理由で *1 、検索ページや、新着情報ページ等が応答を返さなくなると、以下の様な症状が発生する。
トップページ
http://www.library.okazaki.aichi.jp/tosho/index.asp[http://www.library.okazaki.aichi.jp/tosho/index.asp] の様に、ASPで生成されるページが応答を返さなくなる。
しかしながら、この時、 http://www.library.okazaki.aichi.jp/tosho/[http://www.library.okazaki.aichi.jp/tosho/] の様なアクセスはエラー応答を返すし。
エラーページ
http://www.library.okazaki.aichi.jp/tosho/collection.html[http://www.library.okazaki.aichi.jp/tosho/collection.html] の様な、ASPを介在しないページは、正常にアクセスができる。
エラーページ
この状態に陥った時に、Cookieを削除してやると、正常にアクセスできるように回復する。
Cookie
つまり、Cookieを頼りに、ASPへの同時アクセスを制限しようとしている様なのだけれども、この時のパケットダンプを見ると、HTTP GETに対するACKを発行したまま、だんまりという状況になっている。
Wireshark
IISでのASPの実装経験が浅いので断言するのは難しいのだけれども、 GETをACKで受けたまま、ASPが安全に終了する様なコードを書くのはきっと難しいはずなので、これは内部的には、実装者が想定していないことが起きている可能性があるのではないかという想像もできる。
だとすると、実際には、このシステムは 500番台のHTTPエラーを出すことは無かったのではないか という疑いも生じるし *2こんなビザンチン障害を発するシステムの応答を見て、自分のせいかも知れないと判断するのは難しい のではなかろうか。
検索ページのソースにも
//2重実行防止
function jfSubmit() {
//alert(document.frmKensaku.hidKensakuF.value);
	if(document.frmKensaku.hidKensakuF.value == "0"){
		document.frmKensaku.hidKensakuF.value = "1";
		return true;
	}else{
		return true;
	}
}
という興味深いコードがある。
以下は上記の観測を基にした推察であるが、このサイトの実装者は、イントラネットで使われる業務システムの様に、サイト利用者はマニュアル通りにシステムを操作し、システム設計者の想定と異なるアクセス操作は行わないという前提でシステムを実装したのではないか。
しかも、制限の仕組みにバグがあって、Cookieの制限に従わない、例えばCookieを食わないブラウザや、スクリプトでアクセスすると、不具合が顕在化してしまう。
本来、インターネットというパブリックな環境においてアクセスされるのが前提であるシステムにおいて、当然想定すべきだった操作を、設計者あるいは実装者が想定していなかったからと言って、公権力の行使という形でユーザーに責任転嫁されるのはとんでもない話だと思う。
*1: 検索ページで、「1%」という書名を検索した際にたまたま発生した。理由は分からない。
*2: (7月22日追記)その後の情報で、 あるリクエストを境に[http://librahack.jp/okazaki-library-case/libra-server-accident.html] 連続してエラーが発生することが判明した。
新たな情報を基にしたメカニズムの推察については、 7月22日の記事[http://www.nantoka.com/~kei/diary/?20100722S1] を参照頂きたい。

この記事に頂いたコメント

Re: 続・robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕 by Zliz    2010/06/21 23:26
like演算を使っていて"%"がワイルドカードになるらしいです。 それで検索に...

■ 関連記事

詳細はこの日の詳細から

2005年06月21日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1ソースネクスト、1,980円のPC用Linux発売[オープンソース]次の記事 >> このエントリーをはてなブックマークに追加

ソフト販売のソースネクスト(東京・港、松田憲幸社長)は、パソコン用基本ソフト(OS)「リナックス」を税込み千九百八十円で発売する。ターボリナックス(東京・港、矢野広一社長と連携し、共同開発した。
(中略)
低価格を武器に、ウィンドウズの寡占市場である個人市場へのリナックス浸透を目指す。
ソースネクスト PC用リナックス \1980, 日経産業新聞, 2005年6月21日
同記事に「ATOK、ワープロ・表計算ソフト、マルチメディアソフトは附属しない。」とありますから、この辺りは別パッケージとして発売されることになるのでしょう。
もちろん、ダウンロードすれば無料なのだけれども、普通のユーザの特に最初の一台にインストールする時は、パッケージがあれば楽な事は多いと思います。
ソースネクストに関しては色々な批判があることも知っていますが、少なくとも「ウィンドウズの寡占市場である個人市場へのリナックス浸透」は歓迎できるところですので、ぜひ頑張って欲しいものです。

■ 関連記事

■2 プロジェクトに関する記事を書く→社内の誰かが発見→注意される[http://publicstaticvoid.main.jp/jugyo_blog/archives/2005/06/post_307.html][日記]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ブログの内容に指摘を受けたことについて[http://publicstaticvoid.main.jp/jugyo_blog/archives/2005/06/post_306.html] の続編。
Webに公開した記事は、それこそ本当にワールドリーダブルで、誰からも見られる。
日記やblogも例外ではないし、SNS等で半閉鎖的なコミュニティにいると、その意識が薄まるかも知れないけれども、将来的にそのコミュニティに誰が入ってくるか分からないのだから、本質的にはワールドリーダブルに公開している事になる。 むしろSNSの方が、実社会と結びついている分、本人と記事内容を結びつけやすいという見方もあるだろう。
技術系blogを書いていると、どうしても仕事に関連したネタを取り上げたくなることはある。自分に課しているルールがいくつかある。
  1. 守秘義務がある場合は書かない
  2. 仕事上、特別に知り得た情報のみに依存した記事は書かない
  3. 仕事に関連した具体的名称は書かない、なるべく一般化する
  4. アイデア自体が価値を持つものは時期が来るまで待つ
1は、当然。このルールを破ったらこの世界で生きては行けない。業界の掟だ。
2は、例えば秘密では無いのだけど、仕事に関連して入手したあるいは借りだした資料に興味深い内容があったというパターン。これはどうしても書きかたっから、例えばWebや刊行されている出版物のみで立論できる範囲で書く。もちろん他のルールに合致すればだが。
3は、もしその記事が具体的名称を書かないと成立しない記事ならば書くべきではないという判断基準。
もし、一般化しては面白くない記事だとすると、それは内部情報の暴露に意味がある記事だと言うことになる。そういう記事は書くべきでないと考えている。
4は、アイデア段階の事を書くと、今は全く検討されていなかったとしても、ひょっとすると特許化を考えた時に障壁になるかも知れない。よそで普遍化していなかったら今の時点で書くのは危険かも知れない。
まだ他にも自分が記事を書く時に気にすることはあるかも知れないし、逆にルールを曲げて書いている記事もあるかも知れないけど、まとめるとこういったところか。
やっている仕事と発注元と内容をセットで書ける仕事は、世の中にほとんど無いのが実情だ。そういう仕事を手がけたいという思いはあるけれども。
固有名詞を出さないように注意して、記事と仕事がノーリレーションになる様に一般化すれば内容としては書けることが多くなるだろう。逆に言うと、一度でも記事中で仕事に直接関連した固有名詞を出すと、書ける内容が将来にわたって制約を受けてしまう。

■ 関連記事

■3 価格.comから流出したメールアドレスに向けてのspam[http://remoteroom.dyndns.org/diary/?date=20050618#p01][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

カカクメソッド[http://www.nantoka.com/~kei/diary/?200505c&to=200505263#T200505263] を提唱する価格.comから流出したメールアドレスによる被害が発生している様です。
価格comサーバ情報漏洩とスパム被害調査[http://www2g.biglobe.ne.jp/~stakasa/nospam_bbs/past/log/020767.html] の掲示板の情報によれば、5月上旬頃にはspamが到着する様になった例もある様で、これが事実だとすれば、盗み出されてから悪用されるまでの期間は非常に短いことになります。

■ 関連記事

■4 “官製SNS”で地域コミュニティ復活 行政スリム化も[http://www.itmedia.co.jp/news/articles/0506/21/news021.html][SNS]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

すばらしい。
SNSで地域の人々と自然に交流してもらいながら、行政に関する意見も吸い上げる計画。 本名参加を原則にし、本人認証を確実にして荒れるのを防ぎつつ、若年層や一人暮らしのサラリーマンなど、地域コミュニティや行政に対して消極的な人々の意見を取り入れられるツールにしたい考えだ。
本人認証を確実にするには、住基カードで認証すると良いだろう。立ち上がりが今ひとつの住基カードの需要が増えて一石二鳥だ。
ログインしているのだから、各ユーザがどういう記事を選んで興味を持って読んでいるのかも知ることができる。声にならない意見を吸い上げることができるのだ。
例えば、行政に対する不満が集まったコミュニティに参加している人や、その記事を熱心に読んでいる人が、どういう地区に住んでいてどういう年齢層の人だという統計情報を得ることができる。どういう人かという個人情報も分かるかも知れないけれども、そういう目的には使用しない約束になっているハズだから問題は無い。
「行政に対して消極的な人々の意見を取り入れられるツール」になりうるのだ。
毎日病院に来ているおばあちゃんが、今日は来なかった。不審に思った病院の職員がSNSへの最終ログイン時刻を調べたところ、毎朝8時頃にはログインするおばあちゃんがログインしていない。これは何かあったかも知れないと、SNS上でご近所コミュニティに書き込み。
書き込みを読んだ近所の人が、おばあちゃんの家に行ってみるたところ、トイレで倒れているおばあちゃんを発見し、すぐに119番した。
発見が早かったために、おばあちゃんは一命を取り留めた。
地域SNSが、また一つ大切な命を救った。
感動的な話が生まれるかも知れない。IPをしゃべる電気ポットがあるから、「ポットの最終使用時刻:2時間前です」等という情報をプロフィール欄に表示するとさらに有効だろう。
地域の飲食店やスーパーの広告を入れるなど、ビジネス化も検討する。
個人と紐付けることができる広告は非常に魅力的だ。
異なるドメインでも一度紐付けてしまえば、自分のドメインで個人情報をトレースすることができる。
例えばの話。「足あと」等の方法で自分のSNS上のページへのアクセス履歴を見ることができるサイトがある。この日記から、フレーム内や隠し画像を使って、履歴が取られるページへのアクセスを発生させれば、アクセス時刻を頼りに、この日記にアクセスした誰かとSNS上の誰かを紐付けることができる。
この紐付けは一度行えば、次回からは自分の日記が発行しているCookieのみで追跡が可能になる。
こういう便利な仕組みを、地域の飲食店やスーパーが活用することによって、1to1マーケティングが可能になっていく。商店街のポイントカード経由で購買情報と結びつけることも可能だろう。
貯えられた情報をもとにすれば、コミュニティを利用する人ひとりひとりが、いつ、どこからアクセスして、何を読んで、何を書いて、何に興味を持っているかが分かる様になるだろう。これはすばらしいことだ。もちろん個人情報は行政の定める目的以外に流用されることは無いから大丈夫だ。
まさに地域の活性化に繋がるツールと言えるだろう。プライバシーに関する懸念を感じる人がいなければの話だけれども。

[和書]1984年[http://www.amazon.co.jp/exec/obidos/ASIN/4150400083/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1]:

県警もSNS派出所を作って、ネット上のトラブルや相談事を受け付けるとか。

■ 関連記事

■5 「作業量ではなく、機能で買う」、KDDIがシステム調達で新方針[http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050620/163017/]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ベンダーに人月単価の引き下げを要請しても、単価が安くスキルが低いSEに担当が変わって品質や生産性が落ちてしまう。
これは全くその通りだと考える。「単価×人月」の枠から出ないとこの状況は改善されない。
機能量を測る方法自体は、ファンクション・ポイント(FP)法という昔からあるものを採用する。すでに、3人の情報システム部員がFP法によるデータ取得と分析に取り組み始めた。
むしろ、「結局、FPなのか」というところが、いかに人月に縛られているかを如実に現していて興味深い。
過去の類似とみなせるプロジェクトでの、EI, EO, EQ, EIF, ILFに対する係数が必要だから、未経験のプロジェクトやアーキテクチャに適用するのは難しい *1
結局、「できあがり図」が見えているプロジェクトはFPが使えるけども、できあがり図が無いプロジェクトをどう見積もるかが次のステージか。

[和書]人月の神話―狼人間を撃つ銀の弾はない[http://www.amazon.co.jp/exec/obidos/ASIN/4894716658/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1]:

cover
著者:Jr.,フレデリック・P. ブルックス, Frederick Phillips,Jr. Brooks, 滝沢 徹, 富沢 昇, 牧野 祐子
出版社:ピアソンエデュケーション
定価:¥ 3,045
発売日:2002/11
ASINコード:4894716658

[和書]失敗のないファンクションポイント法[http://www.amazon.co.jp/exec/obidos/ASIN/4822281442/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1]:

*1: 他の組織が作った係数を利用する方法はあるし、この共有が行われているのがFPを選ぶ理由であったりするのだけれども。

■ 関連記事

■6蔵書管理<< 前の記事 このエントリーをはてなブックマークに追加

以前、 オライリーの蔵書[http://www.nantoka.com/~kei/diary/?200110#T200110112] を調べて「同じ本を2冊購入してしまう事故防止。i-systemの威力で本屋さんでも参照可能」とか喜んでいたのに、またやってしまった。
本格的な蔵書管理システムの開発が必要だ。

■ 関連記事

詳細はこの日の詳細から

2001年06月21日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 日記バード[http://www.nantoka.com/~kei/nb/]次の記事 >> このエントリーをはてなブックマークに追加

止まっていました。 プロセスが死んだときに、ロックファイルを消せなかったらしい。 ロックの仕組みは、
sub StartLock {
        my ($count);

        while (!symlink("lock.$$", "$LockFile")) {
                if ($count >= 10) {
                        exit(1);
                }
                $count++;
                sleep(30);
        }
}

sub EndLock {
        unlink($LockFile);
}
っていう安直なものなのですが、プロセスIDがすぐ分かるのは利点。

■ 関連記事

■2 一般常識診断[http://kiwi-us.com/~knp3/judge/cs.shtml][ぐる]<< 前の記事 このエントリーをはてなブックマークに追加

けろぴー星人の日記[http://kotone.bunkasha.co.jp/~kenjo/diary-0106.html#0619_3] から。
あなたのジャンル別の成績
ジャンル   正解率
政治       90.0%
経済       90.0%
法律       50.0%
歴史       40.0%
国語       50.0%
国語・歴史が弱いのは自覚していた通り。法律は不本意。

■ 関連記事

詳細はこの日の詳細から

2000年06月21日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 タイムマシン(本物)[http://auctions.yahoo.co.jp/jp/auction/13508734][CLIP]次の記事 >> このエントリーをはてなブックマークに追加

開発に成功したらしい。

■ 関連記事

■2amandaクライアントの追加[freebsd][おしごと]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

新しく導入したサーバにamandaクライアントを導入して、バックアップ対象に追加。
お手軽に、 amanda-2.4.1.tgz[ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-stable/All/amanda-2.4.1.tgz] を使って、パッケージから導入。 グラフ作成等の機能は要らないので、pkg_add -f amanda-2.4.1.tgz として依存関係は無視してOK。
/usr/local/libexec/amanda/patch-system スクリプトを実行して、 servicesとinetd.confを書き換え、inetdをkill -HUPする。
クライアントを実行するユーザーを作らないといけないので、 vipwして、operatorにシェルとホームディレクトリを与える。 ホームディレクトリはrootの持ち物にし、 .amandahostsに、.rhostsを書くのと同じ要領で、サーバホストとoperatorを書く。
===== /usr/guest/operator/.amandahosts
XXXX.XXXX.nanet.co.jp operator
サーバ側の設定は、/usr/local/etc/amanda/dailyset/disklistに、
# XXXX.XXXX.org
XXXX.XXXX.org     wd0s1a  nocomp-root     net10   #    63503 /
XXXX.XXXX.org     wd0s1d  comp-high       net10   #   959815 /home
XXXX.XXXX.org     wd0s1f  temp-partition  net10   #   254063 /tmp
XXXX.XXXX.org     wd0s1g  comp-user       net10   #   508143 /usr
XXXX.XXXX.org     wd0s1h  comp-user       net10   #   508143 /usr/local
XXXX.XXXX.org     wd0s1e  comp-user       net10   #   508143 /var
等、バックアップしたいサーバとディスクを追加。 operatorになって、amcheck dailysetして確認。

IPFWの設定:

rc.confに書いて、firewall.confも書いた。 再起動するまで有効になっていないので、隙をみて再起動するのを忘れない事。

■ 関連記事

■3ぐる[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ここんとこ、忙しくてぐるぐるできませんでした。

JavaのGC[http://www2.willy.co.jp/~s-tomo/diary/?200006b&to=200006191#200006191]:

どこかにGCの実装について、パフォーマンスに与える影響を比較してたページがあったんですが、 見つけ出せないですね。有名なページだったら教えてください。

■ 関連記事

■4某案件[おしごと]<< 前の記事 このエントリーをはてなブックマークに追加

機能間の接続を図にしてみたら、機能モジュールが非対称になってて、 ネイティブと中間形式への変換を、入力と出力で、 各々違う大項目に属する機能が担当することになっていることが発覚。
  • 非対称でもこのまま進む(中間形式の入出力実装を違うグループがやったら危ない)
  • なんとか外部仕様書を変更する
  • 外部仕様書の解釈における見解の相違ということで、内部設計書で軌道修正する。
うーん。

■ 関連記事

詳細はこの日の詳細から

以上、12 日分です。

指定日の日記を表示

前月 2020年08月 翌月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project