前回、 JIPDECからの中間報告[http://www.nantoka.com/~kei/diary/?20120718S1#T201207181S3] を頂いていましたが、7月27日に、ようやく、正式な報告を受領しました。 CCCからの報告としては、前回の日記で書いた通り、 当社業務の適正な実施に著しい支障を及ぼすことから、「個人情報保護法第25 条第１項二」に則り、開示をお断りしている。 というものであった様ですが、 プライバシーマーク付与事業者である当該事業者においては、JIS Q 15001 の要求事項3.4.4.5にある通り、開示しない理由を説明する義務があると当事務局では考えます。 当該事業者の【業務に著しい支障があるため】との説明は、JIS Q 15001 の要求事項3.4.4.5 の例外事項b)に該当することの説明であり、開示しないことの理由の説明とは考え難いものであるこ

岡崎市立中央図書館事件[http://www26.atwiki.jp/librahack/] を見ても感じるのだが、ひどいシステムを導入あるいはひどい運用をされているにも関わらず、発注側担当者が開発会社あるいは運用会社をかばうという「IT版ストックホルムシンドローム」が、自治体においては良く見られる。 ストックホルムシンドローム[http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%88%E3%83%83%E3%82%AF%E3%83%9B%E3%83%AB%E3%83%A0%E7%97%87%E5%80%99%E7%BE%A4] とは、 犯罪被害者が、犯人と一時的に時間や場所を共有することによって、過度の同情さらには好意等の特別な依存感情を抱くことをいう。 (中略) 「警察が突入すれば人質は全員殺害する」となれば、人質は警察が突入すると身の危険が生じる

と書いたのだが、他の図書館でも、一度タイムアウトすると、同じCookieを持ってアクセスすると応答がなくなるという同様の現象が発生するところが見つかった。 気づいたのはたまたまだったのだが、 岡崎市立図書館と同じ、MELILを採用している図書館のリストが、 日本のソフト別OPACリスト[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil] にあり、この中で検索ページが.aspになっているものでは同じ現象が発生する様で、発生条件もかなり緩く、 検索などでのタイムアウト発生 応答が遅かった場合のキャンセル 検索結果ページを閲覧していて、画面内の戻るボタン以外でページ遷移を行った場合 に、以降の応答がなくなるという症状が発生する様だ。 検索ページが.aspxになっているものでは、確認した範囲では発生を見ていないので、これは後に改修されたの

タイトルを付け直そうかと思ったが、まだ続くかも知れないのでシリーズ化することにした。 初出の時に サーバ側から観測した時に、相手が行っているのが過剰なクロールか、あるいはDoSなのかは、Webサーバのログでも大体見当は付く インターネットでは、専用線接続やクラサバとは根本的に異なり、ネットの向こうには何があるのか分からないというのがスタートラインだ。これは、インターネット全盛の今にあっては当たり前のことだが、レガシー世界からすると、クライアントが何かも分からないというのは確かに別世界だ。 レガシー世界のサーバとクライアントは一対のものとして実装され、お互いの挙動を把握しながら動いていた。 ところが、インターネットの世界では、 RFC[http://ja.wikipedia.org/wiki/Request_for_Comments] で提案されたプロトコルを拠り所に、サーバとクライアントが

容疑者とされた当人が、 Librahack[http://librahack.jp/] として、顛末を説明している。 想像通り、端的に言えば、図書館ページが提供するインターフェイスが使いにくいので、スクレイピングして、検索しやすいデータベースを用意しようとした。ということの様だ。 だとすると、 前の記事[http://www.nantoka.com/~kei/diary/?20100526S2] でも書いたけれども、こんなことで逮捕される様では、技術的な実験も研究も、全て、逮捕を覚悟して掛らなければならないということになる。結果、技術の進歩を著しく阻害する危険性がある。 こんなことが起これば、日本でGoogleの様な、あるいはGoogleを超えるサービスを開発しようとは思わなくなる。 実際、図書館の蔵書データベースを無償で提供している カーリル[http://calil.jp/] というサ

#Librahack[http://twitter.com/search?q=%23librahack] の議論。多く登場する「スクレイピング」と書こうと思ったけれども、クロールで得たHTMLの後処理がスクレイピングだから、ここでは「クロール」対「DoS」とした。 そもそも、クロールとDoSは行っている側の目的に決定的な違いがある。 クロールを行う際は、クロールによって相手サーバの情報を取得することが目的だ。そのために、リクエストに対する応答を受け取って、そのまま保存するなり、何らかの加工（スクレイピング）を行って、情報を保存する。 情報を得るのが目的だから、サーバが落ちるのは困る立場だ。 一般的な作りとしては、ページのリクエストを出して、結果を受け取ったら、その場で解釈して、次にリクエストを出すページを決めるか、あるいは予め予定している次のページのリクエストを出す。この間に待ち時間を入れ

続・robots.txtに従わず、図書館ＨＰにアクセス３万３千回　業務妨害容疑で男逮捕2010-06-21 シリーズ・クロールとDoSの違いと業務妨害罪と(12) - 図書館の自由に関する宣言を考える2010-08-23 岡崎市立中央図書館事件に関する本日誌の記事一覧2010-08-17 シリーズ・クロールとDoSの違いと業務妨害罪と(4)2010-07-18 シリーズ・クロールとDoSの違いと業務妨害罪と(36) - 「図書館ホームページ閲覧障害に係る経過等について」2011-02-26 シリーズ・クロールとDoSの違いと業務妨害罪と(10) - 動かないコンピュータ2010-08-06 「脱線」便乗詐欺が数十人？　ＪＲ西、不審者リスト提出2005-06-07 robots.txtに従わず、図書館ＨＰにアクセス３万３千回　業務妨害容疑で男逮捕2010-05-26 シリーズ・クロールとDo