サーバ管理者日誌サーバ管理者日誌サーバ管理とそれ以外の日常を綴ります。メールはkei@nantoka.comまで。いう主張をしておきたいと考えました。武雄市図書館の読書履歴の扱いの問題とつながる部分もあると思い、シリーズに含めました。掲載して頂いた報告について、許諾を頂くことができましたので転載いたします。図については、発表時に使用したスライドを掲載しております。はじめに:図書館におけるプライバシー情報について,情報セキュリティを専門としている利用者の立場から考えてきたことを発表させて頂きました。いう問いかけをきっかけとして,図書館を外から見てきたシステム技術者として考えた部分を軸にして,図書館システムとシステムが扱う情報についてまとめたものです。発表の場では検討していなかった点について,他の方の研究報告および討議の場で,新たに気づかされた重要な問題がいくつかありました。その点についても,補足させて頂きたいと思います。「削除」のあいまいさ:「履歴を残す・残さないの,0と1の間」として,技術者として,まず気になる事が「削除」という言葉のあいまいさです。これは図書館システムに限らず,広くITシステムに共通することですが,「データを削除する」という仕様を与えられた時に,システムを作る側は「データを削除しても良い」と解釈しがちです。データの削除にはリスクが伴います。他の帳票を出力するために必要ではないかとか,集計時に必要となるのではないかとか,何らかの障害が発生した際に必要になるのではないかという点を考慮すると,システムを作る側にとって,削除は簡単な問題ではありません。「返却時に貸出情報を削除する」という仕様についても,これを本当に厳密に実現することは,設計時から例えば「返却時に利用者と貸出履歴の紐づけは抹消され,システム内に残存しないこと」といった様な仕様を掲げ,アプリケーションだけでなく,データベースやハードウェア,運用まで,この要件を満たす様に設計しなければならないでしょう。「システム内に残存しない」という要求にもいくつかのレベルがあります。図書館システムから見えないのか,データベースにも残らないのか,ジャーナルやバックアップにも残らないのか,どのレベルを要求するかで実現の難しさは変わってくると思いますが,ジャーナルやバックアップにも残らないことを保証しようとすれば,障害対応とのバランスの中で,実現の難しさは相当に上がってきます。これを実現するために相当の注意を払って設計と実装が行われていますし,使用されるハードウェアにも堅牢さが要求されてきます。当然ながらこれはコストに反映されます。図書館システムに戻って「返却時に貸出履歴を削除します」ということについて,実際にはどのレベルで削除が行われているのか,必ずしも多くの図書館員の方が明確な答えを持っているとは言えないのではないかと感じます。他のシステム同様,図書館システムも,アプリケーションデータベースファイルシステム物理デバイスという層でデータを取り扱うことになりますが,アプリケーションのレベルでの削除。自分が見える画面から見えなくなるから削除されているという認識を持っておられる方が大半なのではないでしょうか。本稿を書くにあたって,実際に公共図書館で「貸出履歴はいつ削除されるのか」「それは,システム上どの様に実現されるのか,内部では統計情報を作るために残っていることはないか」という質問をさせて頂きました。前者については「返却時に削除される」と回答頂くのですが,後者の質問に関しては,その場で明確な回答を頂くことはできませんでした。新氏の発表や討議を通じて得た情報から考えますと,画面からは参照できなくとも,履歴情報が一定期間保存されている図書館システムも存在するというのが実情の様です。この場合「返却時に削除します」という説明は,図書館員の方から見える範囲では間違いではないのかも知れませんが,利用者にとっては正確ではないでしょう。岡崎市の図書館で起きたLibraHack事件を振り返りますと,図書館員の方の図書館システムに対する見方と言いますか,姿勢にもどかしさを感じることが多くありました。極端な表現かも知れませんが,図書館システムの問題はシステムの問題であって図書館の問題では無いと言う様な姿勢です。LibraHack事件は,まさにその様な姿勢を背景にして起きた事件とみることができると思います。一部の図書館員の方には,図書館システムはベンダーに任せているもので,自らは単なるシステムの利用者という認識があるのかも知れませんが,図書館利用者に対する責任は図書館自らが負うべきものであって,決してベンダー任せにできるものではないと考えます。情報システムの中で扱われている個人情報について,個人情報を取り扱う企業自らが責任を負わなければならないという立場で,システムの中での個人情報の扱いを明確化する取り組みが行われてきました。図書館においても,図書館システムの中でどの様に貸出履歴等の個人に関する情報が扱われているかを図書館員自らが正確に把握し,責任を持って対応できるようにすることが急務だと考えます。匿名化情報の利用:図書館では貸出履歴を元にして,多くの統計情報を作成しています。これらの統計情報は利用者個人から切り離されていますが,切り離されたはずの情報が,再び個人と結びつく事がないかという点については,慎重な検討が必要だと考えます。「この本を借りた人は,こんな本も借りています」という情報は,ある利用者が借りた本の中に家族や周辺の人に知られたくない本が混じっていた場合,知られたくなかった貸出履歴を推察される可能性があります。確実に特定されることはなくとも「この本を借りるのはあの人くらいだろう。こんな本も借りているのではないか。」等と推察され,それが確からしく見える状況があれば,仮に誤っていたとしても利用者のプライバシーを侵害するのではないでしょうか。この様な関連を,例えばリコメンドとしてWebOPACで提供した場合,長期的に収集した上で分析し,情報の提供側が想定していなかったつながりを導きだされる可能性を考慮しておく必要があります。いわゆる「ビッグデータ」や「データマイニング」として,大量のデータから,コンピュータの能力を使って関連性を見つけ出す技術が近年は個人でも使える様な状況になっています。これらの手法によれば,長期間にわたって,例えば同じ曜日に来館することが多い,どういう雑誌を借りることが多いと言った特徴を見つけ出して,関連するデータをつなぎ合わせて追跡できる可能性が生じてきます。利用者の情報を削除したリコメンドデータであっても,この様な関連性に基づいて追跡が行われれば,ある時点で本を借りていた人が特定されると,関連する履歴がその利用者のものであることを特定されることにつながる可能性があります。この様に,全てのリコメンドデータを収集し続けて分析することは,今日では非現実的ではありません。回線のコストは十分に安くなり,記憶媒体のコストもハードディスクの場合,この15年間で千分の一まで安くなっています。コンピュータの処理能力も向上する一方です。数年間にわたって,図書館の全リコメンドデータを収集して分析して,こういった追跡を行うことは個人でも実現できる状況にあります。ネットへの公開は,全てのデータを収集され,分析されても大丈夫かと言う観点で,プライバシーへの影響を検討されなければならないと考えます。その先へ:一方で,読書履歴を本人がライフログの一部として蓄積することや,大量の履歴データを活用して新たな本との出会いを得たりするサービスは非常に魅力的ですし,SNSの普及等から,自分の読書履歴の一部を積極的に公開したいという利用者も存在します。私自身も,図書館で借りた本をブログに記録することがあります。自らが読んだ本を後で探し出すことができたり,本に関連したブログ記事を書いたりする際に大いに役立っていますし,本を媒体にしたコミュニケーションは,新しい本や人や世界との出会いを生むでしょう。そこで図書館がこれらのサービスを提供する事について検討してみたいと思います。希望者だけに提供するサービスであれば,本人の同意を得ている事から,個人情報保護法上の問題はないと考えられます。希望者のみに対する付加サービスと位置づけ,誘導とならない様な配慮があれば,サービスを利用する圧力となる懸念もないと考える事ができるでしょう。希望者のみを対象としても,図書館が読書履歴を蓄積するサービスを提供する事は,他の利用者あるいは他の図書館の利用者に対して,希望の有無に関わらず過去の履歴を保存しているのではないかという懸念を招く不安が残ります。読書履歴の扱いに不安を生むようなサービスであれば,それが一部の人に便利に利用されるとしても,公共図書館としては受け入れがたいサービスだと思います。一方で,前述した様に読書履歴の活用によって大きく広がる世界があります。ここで,「自分は知られても構わない」とか,「説明して同意を得ているのだから構わない」という論で物事を進めてしまえば,利用者のためのはずのサービス提供が,図書館の信頼を損なうという本末転倒な状況を生じることになります。ここで,二項対立としてしまうのではなく,読書履歴は利用者のものだという原点に立ち返って,図書館としては,まず利用者が貸出中の資料の情報を取得する手段を提供する事に専念して,そこから先のサービスの利用は利用者に任せるという枠組みが構築できないでしょうか。予約完了した図書名が登録したメールアドレスに送られてくるという仕組みを提供している図書館は既にあります。提供し,Twitter等に見られる様に利用者が希望する外部の利用者が希望するアプリケーションから取得できる仕組みを提供すれば,利用者は自由に外部のサービスを選択し,あるいは自作して,自らの読書履歴を利用したサービスを受ける事ができる様になると思います。利用者は自分が利用したいWeb本棚サービスにログインし,図書館を選択して「貸出中の図書の取り込み」ボタンを押すと,図書館の画面に転送され,そこでWebOPACの認証をすると,貸出中の図書の一覧が表示され,Web本棚サービスに登録したい資料にチェックを付けて,「送信」ボタンを押せば,Web本棚サービスにチェックを付けた資料の一覧が送信されるといった仕組みが実現できます。Web本棚サービスでは,書誌情報をOpenURL経由で取得するなどして,Web本棚に貸出中の書籍を取り込むことができます。利用者が選択したサービスについては,自動的に処理を行えるようにすることもできるでしょうし,利用を止めたくなったら,図書館側で特定のサービスからのアクセスを停止するような機能を持たせることもできるでしょう。この様に,図書館と読書履歴を利用したサービスを分離することには以下の様なメリットがあります。図書館は貸出を管理するために利用者と個人を結びつける必要がありますが,外部サービスには必ずしもその必要がありません。アプリケーション連携をする際に,利用者IDや個人名等の情報を図書館から提供する必要もありません。利用者は匿名で外部のサービスを利用することができます。今現在,貸出中の資料の情報を渡すという仕組みになっていますから,図書館自身が履歴を蓄積しているとの懸念を招きません。利用者はサービスを自由に選ぶ事ができ,複数のサービスを同時に使う事も,目的に応じて使い分ける事もできます。全ての読書履歴をライフログとして自分だけが見られる様に記録し,周囲に知らせたい読書履歴をSNSで共有し,特定のテーマの本を公開された仮想本棚に並べて,ネット上の知人と意見交換をするといった利用が可能になるでしょう。サービスの使用をやめることも利用している図書館とは関係なく自由にできます。転居等で利用する図書館が変わる場合があります,図書館に依存しない外部のサービスであれば,各図書館での読書履歴を集約することも継続して管理することもできます。リコメンドサービスの提供しやすさ多数の読書履歴から,関連性のあるものを抽出してリコメンドを行う様なサービスを提供する場合,リコメンドから貸出履歴を推察される懸念があります。対象の地域が狭く,人数が少ない場合ほど特定される危険性は高まりますが,外部サービスの場合は,一般的にサービス提供者が地理的に広く,また多くの利用者の履歴を扱う事によって,対象者が多くなることから推察のリスクを下げつつ,より多くの履歴を使って有益な情報を提供できる様になるでしょう。同じ読書傾向を持つ人を紹介する様なサービスを提供する事は,図書館自身が行う場合は個人情報の取扱いの兼ね合いから,困難な部分もあると考えます。希望者だけが匿名(仮名)で参加する様なサービスであれば,似た読書傾向を持つ人を見つけたり,関心のある分野の本を本棚に並べている人を「フォロー」して,その人が読んだ本を案内してもらったりというサービスの展開も可能となるでしょう。この様に考えると,図書館自身が各々これらのサービスを利用者に提供することよりも,共通した枠組みを作り,サービスの発展を促し,あるいはこの様なサービスの構築に参加していくようなアプローチが,利用者にとって,より魅力的な環境を生み出すのではないかと考えますし,大いに期待します。他の方の発表と討議を受けて:ここまで私自身の発表をまとめてきましたが,シンポジウムでの他の方の発表と討議を受けて,新たに知ったことと考えてことについてまとめておきたいと思います。新氏の読書履歴が参照できる機能を標準で持った図書館システムがあるとの発表について。私も驚きましたし,恐らく多くの図書館員の方も驚かれたことと思いますが,その後の討議で,この様なシステムは決して例外的な存在ではなく,館種によっては問題とならないケースもあり,カスタマイズによってその様な画面を削除しているケースがあるということを知りました。貸出履歴が閲覧できる図書館システムが公共図書館に導入されているのではないかと言う問題は,重要な問題提起だったと考えます。この様な図書館では利用者に「この図書館では貸出履歴は返却後も残りますが,外部には決して漏らしません」という正確な説明をしているのでしょうか。図書館システムを通じて実際には履歴を見ることができるのにも関わらず,「削除しています」という説明をしている様なことがあれば,これは図書館あるいは図書館員の倫理にも反することですし,個人情報保護法上も問題となる行為です。図書館員の方が自ら,自館の図書館システムの機能を把握して,利用者に正しい説明を行える知識を持つことが必要だと思います。履歴が残される場合,改修を行う対策もあると思いますが,すぐに改修を行えない場合,これは「寝た子を起こす」という様な不安もあって大変な判断ではあると思うのですが,何らかの形で利用者にその事実を伝えるべきであると思います。ある程度,図書館に詳しい利用者は「宣言」を図書館に期待していますし「貸出業務へのコンピュータ導入に伴う個人情報の保護に関する基準」で示された「貸出記録は,資料が返却されたらできるだけすみやかに消去しなければならない」という基準が守られるのが普通だと認識しているでしょう。「基準」の存在は知らなくとも「読書履歴は返却と同時に削除される」と理解している利用者はおおいはずです。示し方には色々な方法があると思います。調べることができます。詳しくはカウンター,電話,メールにてお問い合わせ下さい。閲覧履歴が取得できるにも関わらず,利用者からの「以前に借りた本を確認したい」「この本は借りたことがあるでしょうか」といった問い合わせに「削除しているので調べることはできません」と答えることは決して許されないと考えます。いずれにしても,閲覧履歴がシステムから参照できる図書館については,システム上,見えなくなっている図書館と比較して,図書館員が利用者の秘密を守る上でより重い責任を負っていることを自覚して頂きたいと思います。討議の場で,捜査関係事項照会についての調査結果を発表頂きました。正確な数字などは記録に譲りますが,利用者の立場からすると意外に感じる程度に多い数字だったと思います。閲覧履歴が残るシステムを使用している図書館において,捜査関係事項照会を受けた場合,どの様に対応するのかということは,しっかり考えておく必要があると思います。データベースのジャーナルの問題についても,整理をしておきたいと思います。ジャーナルファイルは,システムに障害が生じた場合に,過去の任意の時点にデータベースの状態を巻き戻すことができる様に記録されるファイルです。これは,様々な事故や障害に備えて作成されるものですが,その性質上,このファイルを入手すれば,過去の任意の時点での貸出状況を抽出することができることになります。いった意味では,ジャーナルファイルは全利用者の全ての貸出履歴が記録されたファイルであると見ることができます。このジャーナルファイルが,利用者の秘密に対して与える問題を整理してみたいと思います。図書館あるいは図書館員が自発的にジャーナルファイルを取り出して,利用者の秘密に介入するという問題については,そもそも図書館や図書館員が秘密を守るとの信用が成り立たなければ,図書館を利用することはできませんから,とりあえず議論の外におきたいと思います。考慮しなければならない問題として,システムを管理する業者がジャーナルファイルを何らかの理由で外部に持ち出す警察の捜査等によって,ジャーナルファイルの提出を求められるといったものが考えられると思います。LibraHack事件では,ジャーナルファイルではありませんが,保守業者が利用者データを含んだファイルを社内に持ち帰り,他のシステムの開発に混在させたことが情報漏洩事件のきっかけになっています。近年のIT技術を基にした捜査技術の進展で,ジャーナルファイルを基にした捜査も考慮する必要が出てきているでしょう。いった場合に,ジャーナルファイルが,「図書館の全ての利用者の秘密を含んだファイルである」という認識を持って,対応することが求められることになると思います。まとめ:以上,図書館を専門としない立場ながら,図書館システムとそこで扱われるプライバシー情報について考えてきたことをまとめさせて頂きました。すれば現場の考慮を欠いた,利用者としてこうあって欲しいという思いに傾きがちだった部分はあるかと思いますが,今回のシンポジウムを通じて,私としても図書館内の実情や事情を知ることができ,さらに深く,図書館とシステムについて考える機会を得られましたことに感謝いたします。川崎市立図書館では、CSVファイルでのダウンロード機能を提供しています。XML等の機械可読な形式で書誌情報を提供するなど。「自分が以前借りた図書を調べることはできますか?」でWeb検索をすると、多くの図書館では「返却時に消去しているので調べることはできない」との回答を示していることが分かります。航空会社と生保会社からバースデーカードが届いた。チキンのトマト煮とサンドイッチみたいなちょっとパーティっぽいばんごはんを作って、ケーキとスパークリングワインを買ってきてみた。Tweetその昔、行きつけだったところが生きてるかなぁって感じで、キャッシュを掘り起こしつつ...あらためてよろしくです。やあ3とこ[http://yar-3.net/d/]:おぉ。ぶだぶ[http://www.fastwave.gr.jp/diarysrv/kiwamoto/]:この背景色は覚えてますよ。「電波とどいた?」[http://ruriko.denpa.org/]:雰囲気変わったかな。銀河の歴史がまた1ページ[http://www.yk.rim.or.jp/~george/jdiary_last.html]:こちらも日記システム変更されたかなぁ。Serviceで情報取ってきて書誌情報を日記に載せてくれると言うシステムを動かしていたのだけど、AWS側がバージョンアップされてたり仕組みが変わってたりして動かない。こんなに面倒だったら、ISBNコードだけ書けば書誌情報inlineで生成してくれるようなWebパーツとか需要があるんじゃなかろうか。言うか、とっくにありそう。Tweetニフティからメールが来て思い出したり。TweetどうもExploitがすぐにでも出回りそうな「予感」がするので、大急ぎで対策。TweetOpenOffice入れたり、PuTTY入れたり、秀丸入れたり、Becky2入れたりして生活環境が整ってきた。前回、他のノートの環境作ったときの履歴が残っていてずいぶん助かった。今回は、制限ユーザー仕様なので、ちょっと苦労はあるけれども。Explorer」なショートカットを作っておけば、大体のことは制限ユーザのままでなんとかなる様だ。Tweet4割が払っていないっていうのがすごい。破綻するにせよ、現在支払っていない人が得をしてしまうのは絶対に問題。制度が破綻するかどうかと、支払わないのは別の問題にしないと、払った人がバカを見ることになりかねない。決まりを守った人が損をするという状況を作ってしまうと、誰も決まりを守らなくなって、社会システムは崩壊する。今回、お盆の休業時期と重なったのは、対策の時間を取れて、幸運だったのかも知れないのに、お盆中は何もできなかったあるいはやらなかったところが多いようだ。パッチを当てること自体にコストが掛かるので、予算の制約上、パッチ当てを「節約」しないといけないという状況にある自治体も多いという大きな問題もある。今後の導入にあたっては、パッチ当てを自動化する仕組みを織り込む等、運用をトータルで考えたシステム設計をする必要があるだろう。日本郵政公社のウイルス感染は保守業者が犯人?[http://www.japanpost.jp/pressrelease/japanese/sonota/030818j902.html]:どこの業者か分かりませんが、大変なことになっていそうです。社内事務のみに使用:このサーバーは社内事務のみに使用しておりますので、お客さまへの影響はありませんでした。今回たまたま、お客さまへの影響がなかっただけということは広く理解されているのでしょうか。「パソコンが使えなくなる→業務が遅れる→お客さんに影響」「ウイルスがメールで内部情報を運び出す→情報漏洩」ということにならなかったのは、幸運によるもので、そういうウイルスに感染する可能性は既にある訳です。Tweet全てのIPトラフィックを独占せよって感じですかね。通信事業は独占によってうまみが出てくるところがあるので、どうしても最後は資本力の勝負になってしまいます。独占によって得るうまみは、当然、利用者が負担する訳で、独占を許さない圧力は必要だと思うのです。かめぬいとペンギン:水族館で買ってきたかめぬいとペンギンをディスプレイの上に並べてみた。お寿司:晩御飯をお寿司屋さんで。Tweetとりあえず実装できた。汎用性を上げたいところ。他の日記システムあるいは既存の日記システムを使っていない環境への対応ってところですかね。その日記システム用のモジュールを呼べば、よろしくやってくれるっていう構造にしたい。オプショナルな要素によっては、その日記システムでは再現できなかったりすると。Exifの中にテキストも埋め込んでしまうとか、LIMGみたいなのを拡張して、日記上にはサムネイルを表示してGPS情報を付加、クリックしたらその場で動的にhtmlファイルを生成する。いうアプローチもあるわけだ。これは現行のアプローチでも解決できてる。後で、コメントを修正あるいは削除する時と、地図リンクやレイアウトを変更したい時の手間を考えると動的生成に軍配が上がりそうだけれども、サーバの負荷は大きそうだ。Tweetタイムリーな話題。いう様なコースを取ることに気づきました。なるので、どうしているのかなぁと気になったのです。調べてみたのですが、結局ある掲示板で、推進運転で入線してくることを教えて頂きました。先頭車にも機関士が乗り込んで、無線で連絡しながら入線してくる模様です。使えなくなって、自動ブレーキになる等という話も知ったり。あれだけ長い編成をバックで運転するのって大変でしょうね。Tweetヘクサでハタチになった。Tweetどっかに売ってないかしらん。集には載っていない模様。Tweet全然サンドボックスになっていないという、またかという問題。これをJavaの問題と誤解するバカが増える心配が。