2013年08月22日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ武雄市TSUTAYA図書館(25) - 『図書館界』65巻2号 第54回研究大会全体報告 図書館における個人情報/プライバシー情報の取り扱い:情報セキュリティの視点から[http://www.nal-lib.jp/kai/v65/cont2.html][武雄市][図書館][TSUTAYA図書館][ビッグデータ] このエントリーをはてなブックマークに追加

Suica履歴提供の問題が話題になる中、貸出履歴の扱いに関して、 熊谷千葉市長と高木浩光セキュリティー専門家とのビッグデータ取り扱いに関する会話[http://togetter.com/li/550187] の様なやり取りがあり、改めて、 貸出履歴から利用者情報を外しただけでは、個人と結びつく可能性は否定できない という指摘や、 個人の読書履歴を活用する主体は利用者自身であるべき という主張をしておきたいと考えました。
武雄市図書館の読書履歴の扱いの問題とつながる部分もあると思い、シリーズに含めました。

2013年3月の日本図書館研究会研究大会のシンポジウムで、 「図書館における個人情報/プライバシー情報の取り扱い:情報セキュリティの視点から」[http://www.nal-lib.jp/events/taikai/2012/report.html#gaiyou2] と題して、この様な話題をお話させて頂きまして、 『図書館界』65巻2号(通巻371号)July, 2013[http://www.nal-lib.jp/kai/v65/cont2.html] に掲載して頂いた報告について、許諾を頂くことができましたので転載いたします。
なお、図については、発表時に使用したスライドを掲載しております。

はじめに:

図書館におけるプライバシー情報について,情報セキュリティを専門としている利用者の立場から考えてきたことを発表させて頂きました。
今回の発表は,前川氏の「履歴を残す・残さないの,0と1の間を考えていく必要があるのではないか」 *1 という問いかけをきっかけとして,図書館を外から見てきたシステム技術者として考えた部分を軸にして,図書館システムとシステムが扱う情報についてまとめたものです。
発表の場では検討していなかった点について,他の方の研究報告および討議の場で,新たに気づかされた重要な問題がいくつかありました。その点についても,補足させて頂きたいと思います。

「削除」のあいまいさ:

「履歴を残す・残さないの,0と1の間」として,技術者として,まず気になる事が「削除」という言葉のあいまいさです。
これは図書館システムに限らず,広くITシステムに共通することですが,「データを削除する」という仕様を与えられた時に,システムを作る側は「データを削除しても良い」と解釈しがちです。
色々なレベルでの「削除」
データの削除にはリスクが伴います。他の帳票を出力するために必要ではないかとか,集計時に必要となるのではないかとか,何らかの障害が発生した際に必要になるのではないかという点を考慮すると,システムを作る側にとって,削除は簡単な問題ではありません。
例えば「返却時に貸出情報を削除する」という仕様についても,これを本当に厳密に実現することは,設計時から例えば「返却時に利用者と貸出履歴の紐づけは抹消され,システム内に残存しないこと」といった様な仕様を掲げ,アプリケーションだけでなく,データベースやハードウェア,運用まで,この要件を満たす様に設計しなければならないでしょう。
「システム内に残存しない」という要求にもいくつかのレベルがあります。
図書館システムから見えないのか,データベースにも残らないのか,ジャーナルやバックアップにも残らないのか,どのレベルを要求するかで実現の難しさは変わってくると思いますが,ジャーナルやバックアップにも残らないことを保証しようとすれば,障害対応とのバランスの中で,実現の難しさは相当に上がってきます。
例えば,クレジットカードの決済を行うシステムは,決済完了時点で暗証番号やカード裏面に記載された確認用の数字(CVV2)がシステムに保存されないことを保証しなければなりません *2 から,これを実現するために相当の注意を払って設計と実装が行われていますし,使用されるハードウェアにも堅牢さが要求されてきます。当然ながらこれはコストに反映されます。
図書館システムに戻って「返却時に貸出履歴を削除します」ということについて,実際にはどのレベルで削除が行われているのか,必ずしも多くの図書館員の方が明確な答えを持っているとは言えないのではないかと感じます。

他のシステム同様,図書館システムも,
  1. アプリケーション
  2. データベース
  3. ファイルシステム
  4. 物理デバイス

という層でデータを取り扱うことになりますが,アプリケーションのレベルでの削除。つまり,自分が見える画面から見えなくなるから削除されているという認識を持っておられる方が大半なのではないでしょうか。本稿を書くにあたって,実際に公共図書館で「貸出履歴はいつ削除されるのか」「それは,システム上どの様に実現されるのか,内部では統計情報を作るために残っていることはないか」という質問をさせて頂きました。前者については「返却時に削除される」と回答頂くのですが,後者の質問に関しては,その場で明確な回答を頂くことはできませんでした。
新氏の発表や討議を通じて得た情報から考えますと,画面からは参照できなくとも,履歴情報が一定期間保存されている図書館システムも存在するというのが実情の様です。
この場合「返却時に削除します」という説明は,図書館員の方から見える範囲では間違いではないのかも知れませんが,利用者にとっては正確ではないでしょう。
岡崎市の図書館で起きたLibraHack事件を振り返りますと,図書館員の方の図書館システムに対する見方と言いますか,姿勢にもどかしさを感じることが多くありました。
やや極端な表現かも知れませんが,図書館システムの問題はシステムの問題であって図書館の問題では無いと言う様な姿勢です。LibraHack事件は,まさにその様な姿勢を背景にして起きた事件とみることができると思います。
一部の図書館員の方には,図書館システムはベンダーに任せているもので,自らは単なるシステムの利用者という認識があるのかも知れませんが,図書館利用者に対する責任は図書館自らが負うべきものであって,決してベンダー任せにできるものではないと考えます。
2005年の個人情報保護法施行以来,情報システムの中で扱われている個人情報について,個人情報を取り扱う企業自らが責任を負わなければならないという立場で,システムの中での個人情報の扱いを明確化する取り組みが行われてきました。
図書館においても,図書館システムの中でどの様に貸出履歴等の個人に関する情報が扱われているかを図書館員自らが正確に把握し,責任を持って対応できるようにすることが急務だと考えます。

匿名化情報の利用:

図書館では貸出履歴を元にして,多くの統計情報を作成しています。これらの統計情報は利用者個人から切り離されていますが,切り離されたはずの情報が,再び個人と結びつく事がないかという点については,慎重な検討が必要だと考えます。
本人の参考に
例えば「この本を借りた人は,こんな本も借りています」という情報は,ある利用者が借りた本の中に家族や周辺の人に知られたくない本が混じっていた場合,知られたくなかった貸出履歴を推察される可能性があります。確実に特定されることはなくとも「この本を借りるのはあの人くらいだろう。こんな本も借りているのではないか。」等と推察され,それが確からしく見える状況があれば,仮に誤っていたとしても利用者のプライバシーを侵害するのではないでしょうか。
リコメンドのため
この様な関連を,例えばリコメンドとしてWebOPACで提供した場合,長期的に収集した上で分析し,情報の提供側が想定していなかったつながりを導きだされる可能性を考慮しておく必要があります。
いわゆる「ビッグデータ」や「データマイニング」として,大量のデータから,コンピュータの能力を使って関連性を見つけ出す技術が近年は個人でも使える様な状況になっています。これらの手法によれば,長期間にわたって,例えば同じ曜日に来館することが多い,どういう雑誌を借りることが多いと言った特徴を見つけ出して,関連するデータをつなぎ合わせて追跡できる可能性が生じてきます。
利用者の情報を削除したリコメンドデータであっても,この様な関連性に基づいて追跡が行われれば,ある時点で本を借りていた人が特定されると,関連する履歴がその利用者のものであることを特定されることにつながる可能性があります。
「どんな本を読んでいるか言ってみたまえ」
この様に,全てのリコメンドデータを収集し続けて分析することは,今日では非現実的ではありません。回線のコストは十分に安くなり,記憶媒体のコストもハードディスクの場合,この15年間で千分の一まで安くなっています。コンピュータの処理能力も向上する一方です。
数年間にわたって,図書館の全リコメンドデータを収集して分析して,こういった追跡を行うことは個人でも実現できる状況にあります。
ネットへの公開は,全てのデータを収集され,分析されても大丈夫かと言う観点で,プライバシーへの影響を検討されなければならないと考えます。

Library 2.0 とその先へ:

本人による読書履歴の活用
一方で,読書履歴を本人がライフログの一部として蓄積することや,大量の履歴データを活用して新たな本との出会いを得たりするサービスは非常に魅力的ですし,SNSの普及等から,自分の読書履歴の一部を積極的に公開したいという利用者も存在します。
私自身も,図書館で借りた本をブログに記録することがあります。自らが読んだ本を後で探し出すことができたり,本に関連したブログ記事を書いたりする際に大いに役立っていますし,本を媒体にしたコミュニケーションは,新しい本や人や世界との出会いを生むでしょう。
そこで図書館がこれらのサービスを提供する事について検討してみたいと思います。
希望者だけに提供するサービスであれば,本人の同意を得ている事から,個人情報保護法上の問題はないと考えられます。また,あくまで希望者のみに対する付加サービスと位置づけ,誘導とならない様な配慮があれば,サービスを利用する圧力となる懸念もないと考える事ができるでしょう。
希望者だけ?同意を取る?
しかしながら,希望者のみを対象としても,図書館が読書履歴を蓄積するサービスを提供する事は,他の利用者あるいは他の図書館の利用者に対して,希望の有無に関わらず過去の履歴を保存しているのではないかという懸念を招く不安が残ります。
読書履歴の扱いに不安を生むようなサービスであれば,それが一部の人に便利に利用されるとしても,公共図書館としては受け入れがたいサービスだと思います。
「活用 vs 読書の秘密」?
一方で,前述した様に読書履歴の活用によって大きく広がる世界があります。ですがここで,「自分は知られても構わない」とか,「説明して同意を得ているのだから構わない」という論で物事を進めてしまえば,利用者のためのはずのサービス提供が,図書館の信頼を損なうという本末転倒な状況を生じることになります。
ここで,二項対立としてしまうのではなく,読書履歴は利用者のものだという原点に立ち返って,図書館としては,まず利用者が貸出中の資料の情報を取得する手段を提供する事に専念して,そこから先のサービスの利用は利用者に任せるという枠組みが構築できないでしょうか。
読書履歴のアプリ連携
WebOPACにログインすれば貸出中の図書名が表示される *3 ,あるいは,予約完了した図書名が登録したメールアドレスに送られてくるという仕組みを提供している図書館は既にあります。
これを発展させて,貸出中の資料の書誌を,図書館の間で統一されコンピュータで処理しやすいフォーマット *4 で提供し,Twitter等に見られる様に利用者が希望する外部の利用者が希望するアプリケーションから取得できる仕組みを提供すれば,利用者は自由に外部のサービスを選択し,あるいは自作して,自らの読書履歴を利用したサービスを受ける事ができる様になると思います。
図書館のアプリ連携イメージ
例えば,利用者は自分が利用したいWeb本棚サービスにログインし,図書館を選択して「貸出中の図書の取り込み」ボタンを押すと,図書館の画面に転送され,そこでWebOPACの認証をすると,貸出中の図書の一覧が表示され,Web本棚サービスに登録したい資料にチェックを付けて,「送信」ボタンを押せば,Web本棚サービスにチェックを付けた資料の一覧が送信されるといった仕組みが実現できます。
Web本棚サービスでは,書誌情報をOpenURL経由で取得するなどして,Web本棚に貸出中の書籍を取り込むことができます。
もちろん,利用者が選択したサービスについては,自動的に処理を行えるようにすることもできるでしょうし,利用を止めたくなったら,図書館側で特定のサービスからのアクセスを停止するような機能を持たせることもできるでしょう。
アプリ連携によるメリット
この様に,図書館と読書履歴を利用したサービスを分離することには以下の様なメリットがあります。

個人情報とサービスの分離
図書館は貸出を管理するために利用者と個人を結びつける必要がありますが,外部サービスには必ずしもその必要がありません。アプリケーション連携をする際に,利用者IDや個人名等の情報を図書館から提供する必要もありません。利用者は匿名で外部のサービスを利用することができます。また,あくまで今現在,貸出中の資料の情報を渡すという仕組みになっていますから,図書館自身が履歴を蓄積しているとの懸念を招きません。
サービス選択の自由
利用者はサービスを自由に選ぶ事ができ,複数のサービスを同時に使う事も,目的に応じて使い分ける事もできます。例えば,全ての読書履歴をライフログとして自分だけが見られる様に記録し,周囲に知らせたい読書履歴をSNSで共有し,特定のテーマの本を公開された仮想本棚に並べて,ネット上の知人と意見交換をするといった利用が可能になるでしょう。また,サービスの使用をやめることも利用している図書館とは関係なく自由にできます。
図書館をまたいだ利用
利用者は複数の図書館を利用しますし, 転居等で利用する図書館が変わる場合があります,図書館に依存しない外部のサービスであれば,各図書館での読書履歴を集約することも継続して管理することもできます。
リコメンドサービスの提供しやすさ
多数の読書履歴から,関連性のあるものを抽出してリコメンドを行う様なサービスを提供する場合,リコメンドから貸出履歴を推察される懸念があります。対象の地域が狭く,人数が少ない場合ほど特定される危険性は高まりますが,外部サービスの場合は,一般的にサービス提供者が地理的に広く,また多くの利用者の履歴を扱う事によって,対象者が多くなることから推察のリスクを下げつつ,より多くの履歴を使って有益な情報を提供できる様になるでしょう。
匿名(仮名)でのつながりの提供
同じ読書傾向を持つ人を紹介する様なサービスを提供する事は,図書館自身が行う場合は個人情報の取扱いの兼ね合いから,困難な部分もあると考えます。希望者だけが匿名(仮名)で参加する様なサービスであれば,似た読書傾向を持つ人を見つけたり,関心のある分野の本を本棚に並べている人を「フォロー」して,その人が読んだ本を案内してもらったりというサービスの展開も可能となるでしょう。

発表まとめ
この様に考えると,図書館自身が各々これらのサービスを利用者に提供することよりも,共通した枠組みを作り,サービスの発展を促し,あるいはこの様なサービスの構築に参加していくようなアプローチが,利用者にとって,より魅力的な環境を生み出すのではないかと考えますし,大いに期待します。

他の方の発表と討議を受けて:

ここまで私自身の発表をまとめてきましたが,シンポジウムでの他の方の発表と討議を受けて,新たに知ったことと考えてことについてまとめておきたいと思います。
新氏の読書履歴が参照できる機能を標準で持った図書館システムがあるとの発表について。私も驚きましたし,恐らく多くの図書館員の方も驚かれたことと思いますが,その後の討議で,この様なシステムは決して例外的な存在ではなく,館種によっては問題とならないケースもあり,カスタマイズによってその様な画面を削除しているケースがあるということを知りました。
しかしながら,貸出履歴が閲覧できる図書館システムが公共図書館に導入されているのではないかと言う問題は,重要な問題提起だったと考えます。
この様な図書館では利用者に「この図書館では貸出履歴は返却後も残りますが,外部には決して漏らしません」という正確な説明をしているのでしょうか。
もし,図書館システムを通じて実際には履歴を見ることができるのにも関わらず,「削除しています」という説明をしている様なことがあれば,これは図書館あるいは図書館員の倫理にも反することですし,個人情報保護法上も問題となる行為です。
まずは図書館員の方が自ら,自館の図書館システムの機能を把握して,利用者に正しい説明を行える知識を持つことが必要だと思います。
履歴が残される場合,改修を行う対策もあると思いますが,すぐに改修を行えない場合,これは「寝た子を起こす」という様な不安もあって大変な判断ではあると思うのですが,何らかの形で利用者にその事実を伝えるべきであると思います。
ある程度,図書館に詳しい利用者は「宣言」を図書館に期待していますし「貸出業務へのコンピュータ導入に伴う個人情報の保護に関する基準」で示された「貸出記録は,資料が返却されたらできるだけすみやかに消去しなければならない」という基準が守られるのが普通だと認識しているでしょう。「基準」の存在は知らなくとも「読書履歴は返却と同時に削除される」と理解している利用者はおおいはずです。
示し方には色々な方法があると思います。例えば,矢祭もったいない図書館では,

Q. 自分が以前借りた図書を調べることはできますか? 調べることができます。詳しくはカウンター,電話,メールにてお問い合わせ下さい。

として,利用者の希望があれば読書履歴を調べることができることを示しています *5
閲覧履歴が取得できるにも関わらず,利用者からの「以前に借りた本を確認したい」「この本は借りたことがあるでしょうか」といった問い合わせに「削除しているので調べることはできません」と答えることは決して許されないと考えます。
いずれにしても,閲覧履歴がシステムから参照できる図書館については,システム上,見えなくなっている図書館と比較して,図書館員が利用者の秘密を守る上でより重い責任を負っていることを自覚して頂きたいと思います。
討議の場で,捜査関係事項照会についての調査結果を発表頂きました。正確な数字などは記録に譲りますが,利用者の立場からすると意外に感じる程度に多い数字だったと思います。
閲覧履歴が残るシステムを使用している図書館において,捜査関係事項照会を受けた場合,どの様に対応するのかということは,しっかり考えておく必要があると思います。
データベースのジャーナルの問題についても,整理をしておきたいと思います。
ジャーナルファイルは,システムに障害が生じた場合に,過去の任意の時点にデータベースの状態を巻き戻すことができる様に記録されるファイルです。
これは,様々な事故や障害に備えて作成されるものですが,その性質上,このファイルを入手すれば,過去の任意の時点での貸出状況を抽出することができることになります。
そういった意味では,ジャーナルファイルは全利用者の全ての貸出履歴が記録されたファイルであると見ることができます。
このジャーナルファイルが,利用者の秘密に対して与える問題を整理してみたいと思います。
図書館あるいは図書館員が自発的にジャーナルファイルを取り出して,利用者の秘密に介入するという問題については,そもそも図書館や図書館員が秘密を守るとの信用が成り立たなければ,図書館を利用することはできませんから,とりあえず議論の外におきたいと思います。
考慮しなければならない問題として,

  1. システムを管理する業者がジャーナルファイルを何らかの理由で外部に持ち出す
  2. 警察の捜査等によって,ジャーナルファイルの提出を求められる

といったものが考えられると思います。
LibraHack事件では,ジャーナルファイルではありませんが,保守業者が利用者データを含んだファイルを社内に持ち帰り,他のシステムの開発に混在させたことが情報漏洩事件のきっかけになっています。
近年のIT技術を基にした捜査技術の進展で,ジャーナルファイルを基にした捜査も考慮する必要が出てきているでしょう。
こういった場合に,ジャーナルファイルが,「図書館の全ての利用者の秘密を含んだファイルである」という認識を持って,対応することが求められることになると思います。

まとめ:

以上,図書館を専門としない立場ながら,図書館システムとそこで扱われるプライバシー情報について考えてきたことをまとめさせて頂きました。ともすれば現場の考慮を欠いた,利用者としてこうあって欲しいという思いに傾きがちだった部分はあるかと思いますが,今回のシンポジウムを通じて,私としても図書館内の実情や事情を知ることができ,さらに深く,図書館とシステムについて考える機会を得られましたことに感謝いたします。

*1: 2012年10月,全国図書館大会第7分科会(図書館の自由)「図書館利用者のプライバシー:ネットワーク時代に関する論点整理」, 前川敦子
*2: Payment Card Industry データセキュリティ基準 Version 2.0, 要件3.2 「承認後に認証データを保存しない」
*3: 川崎市立図書館では、CSVファイルでのダウンロード機能を提供しています。
*4: OpenURL受信機能を備え,JSON, XML等の機械可読な形式で書誌情報を提供するなど。
*5: 「自分が以前借りた図書を調べることはできますか?」でWeb検索をすると、多くの図書館では「返却時に消去しているので調べることはできない」との回答を示していることが分かります。

■ 関連記事

詳細はこの日の詳細から

2009年08月22日()<< 前の日記 | 次の日記 >>
この日の詳細

■1たんじょうび次の記事 >> このエントリーをはてなブックマークに追加

だった。
航空会社と生保会社からバースデーカードが届いた。
チキンのトマト煮とサンドイッチみたいなちょっとパーティっぽいばんごはんを作って、ケーキとスパークリングワインを買ってきてみた。
過去の誕生日の過ごし方の様子は、 これまでのこの日[http://www.nantoka.com/~kei/diary/?0822] からどうぞ。

■ 関連記事

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

その昔、行きつけだったところが生きてるかなぁって感じで、キャッシュを掘り起こしつつ…あらためてよろしくです。

やあ3とこ[http://yar-3.net/d/]:

おぉ。まだちゃんとあった!しかもhns!

たぶだぶ[http://www.fastwave.gr.jp/diarysrv/kiwamoto/]:

この背景色は覚えてますよ。古色蒼然。

「電波とどいた?」[http://ruriko.denpa.org/]:

雰囲気変わったかな。

銀河の歴史がまた1ページ[http://www.yk.rim.or.jp/~george/jdiary_last.html]:

こちらも日記システム変更されたかなぁ。

びー・えす・でぃー日誌[http://www.bsddiary.net/d/]:

今日の育児シリーズの気持ちが分かる状況に…日齢ってhnsのユーザ変数で出せたっけ?

■ 関連記事

■3HNSAWS[hns]<< 前の記事 このエントリーをはてなブックマークに追加

その昔、ASINコードを書くと、Amazon Web Serviceで情報取ってきて書誌情報を日記に載せてくれると言うシステムを動かしていたのだけど、AWS側がバージョンアップされてたり仕組みが変わってたりして動かない。
こんなに面倒だったら、ISBNコードだけ書けば書誌情報inlineで生成してくれるようなWebパーツとか需要があるんじゃなかろうか。と言うか、とっくにありそう。

■ 関連記事

詳細はこの日の詳細から

2005年08月22日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1おたんじょうび次の記事 >> このエントリーをはてなブックマークに追加

ニフティからメールが来て思い出したり。

■ 関連記事

■2 Acrobat / Adobe Reader プラグインのバッファオーバーフローの脆弱性に関するセキュリティ情報[http://support.adobe.co.jp/faq/faq/qadoc.sv?226798+002][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

どうもExploitがすぐにでも出回りそうな「予感」がするので、大急ぎで対策。

■ 関連記事

■3環境整備[CF-R4]<< 前の記事 このエントリーをはてなブックマークに追加

OpenOffice入れたり、PuTTY入れたり、秀丸入れたり、Becky2入れたりして生活環境が整ってきた。前回、他のノートの環境作ったときの履歴が残っていてずいぶん助かった。
今回は、制限ユーザー仕様なので、ちょっと苦労はあるけれども。「sudo Explorer」なショートカットを作っておけば、大体のことは制限ユーザのままでなんとかなる様だ。

■ 関連記事

詳細はこの日の詳細から

2003年08月22日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 国民年金未納の場合、個人年金控除なしに 厚労省方針[http://www.asahi.com/politics/update/0822/002.html]次の記事 >> このエントリーをはてなブックマークに追加

4割が払っていないっていうのがすごい。
いずれ破綻するにせよ、現在支払っていない人が得をしてしまうのは絶対に問題。制度が破綻するかどうかと、支払わないのは別の問題にしないと、払った人がバカを見ることになりかねない。決まりを守った人が損をするという状況を作ってしまうと、誰も決まりを守らなくなって、社会システムは崩壊する。

■ 関連記事

■2 ブラスターと後続ウイルスの教訓〜電子政府・電子自治体は大丈夫?[http://www.mainichi.co.jp/digital/coverstory/archive/200308/20/1.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

自治体のウイルス感染いぜん拡大[http://www.mainichi.co.jp/digital/network/archive/200308/20/3.html] も。
今回、お盆の休業時期と重なったのは、対策の時間を取れて、幸運だったのかも知れないのに、お盆中は何もできなかったあるいはやらなかったところが多いようだ。
パッチを当てること自体にコストが掛かるので、予算の制約上、パッチ当てを「節約」しないといけないという状況にある自治体も多いという大きな問題もある。 今後の導入にあたっては、パッチ当てを自動化する仕組みを織り込む等、運用をトータルで考えたシステム設計をする必要があるだろう。

日本郵政公社のウイルス感染は保守業者が犯人?[http://www.japanpost.jp/pressrelease/japanese/sonota/030818j902.html]:

どこの業者か分かりませんが、大変なことになっていそうです。

社内事務のみに使用:

このサーバーは社内事務のみに使用しておりますので、お客さまへの影響はありませんでした。
今回たまたま、お客さまへの影響がなかっただけということは広く理解されているのでしょうか。
「パソコンが使えなくなる→業務が遅れる→お客さんに影響」「ウイルスがメールで内部情報を運び出す→情報漏洩」ということにならなかったのは、幸運によるもので、そういうウイルスに感染する可能性は既にある訳です。

■ 関連記事

■3 NTT、IIJを傘下に[http://www.nikkei.co.jp/news/main/20030821AT1D2100721082003.html]<< 前の記事 このエントリーをはてなブックマークに追加

全てのIPトラフィックを独占せよって感じですかね。 通信事業は独占によってうまみが出てくるところがあるので、どうしても最後は資本力の勝負になってしまいます。 独占によって得るうまみは、当然、利用者が負担する訳で、独占を許さない圧力は必要だと思うのです。

■ 関連記事

詳細はこの日の詳細から

2002年08月22日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1SYA!nikki[SYA!nikki]次の記事 >> このエントリーをはてなブックマークに追加

1359 かめぬいとペンギン:

1554 タテ位置でのテスト:

2038 お寿司:

■ 関連記事

■2 続・写日記計画[http://www.nantoka.com/~kei/diary/?200208b&to=200208122#T200208122][写日記]<< 前の記事 このエントリーをはてなブックマークに追加

とりあえず実装できた。
もう少し汎用性を上げたいところ。今後の課題。
  • 複数jpgファイルが入っているメールをうまくレイアウトする(タテ・ヨコの混在?)
  • レイアウトテンプレートの分離
  • レイアウトの一括変更
  • 他の日記システムあるいは既存の日記システムを使っていない環境への対応
ってところですかね。 他の日記システムとのインターフェイスは、日付と内容を連想配列に入れて、 その日記システム用のモジュールを呼べば、よろしくやってくれるっていう構造にしたい。 オプショナルな要素によっては、その日記システムでは再現できなかったりすると。

動的生成するアプローチ:

考えてみると、データの持ち方について、 Exifの中にテキストも埋め込んでしまうとか、LIMGみたいなのを拡張して、日記上にはサムネイルを表示してGPS情報を付加、クリックしたらその場で動的にhtmlファイルを生成する。 というアプローチもあるわけだ。
今まで一番面倒だと感じていたのが、サムネイル画像を作って、必要ならhtmlファイルも書いて、それらをアップロードして、やっとLIMGが書ける…という部分だったので、 これは現行のアプローチでも解決できてる。
後で、コメントを修正あるいは削除する時と、地図リンクやレイアウトを変更したい時の手間を考えると動的生成に軍配が上がりそうだけれども、サーバの負荷は大きそうだ。

■ 関連記事

詳細はこの日の詳細から

2001年08月22日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 客レのブレーキ[http://www.fastwave.gr.jp/diarysrv/kiwamoto/200108a.html#20010810-2][鉄道]次の記事 >> このエントリーをはてなブックマークに追加

タイムリーな話題。
時刻表を見ていて、カシオペアや北斗星が上野から札幌に向けて出発するときに、 尾久→上野→東北本線という様なコースを取ることに気づきました。
上野からみると、 尾久も大宮も同じ方向[../upload/ueno-oku.gif] になるので、どうしているのかなぁと気になったのです。 で色々調べてみたのですが、結局ある掲示板で、推進運転で入線してくることを教えて頂きました。 先頭車にも機関士が乗り込んで、無線で連絡しながら入線してくる模様です。
これに関係して、 カシオペアにカヤつないだ時[http://www.fastwave.gr.jp/diarysrv/kiwamoto/200108c.html#20010821-8] は、 電気指令式空気ブレーキ[http://www.city.niitsu.niigata.jp/mgr/railoil/rail/unten/mame.html#13] が使えなくなって、自動ブレーキになる等という話も知ったり。
しかしあれだけ長い編成をバックで運転するのって大変でしょうね。

■ 関連記事

■2誕生日<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ヘクサでハタチになった。

■ 関連記事

■3 Code Red[http://www.mountaindew.com/code_red/code_red_frames.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

どっかに売ってないかしらん。 FAQ[http://www.microsoft.com/japan/technet/security/codefaq.asp] 集には載っていない模様。

■ 関連記事

■4 プライスロト[http://www.ipa.go.jp/security/ciadr/20010820java_browser.html][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

全然サンドボックスになっていないという、またかという問題。 これをJavaの問題と誤解するバカが増える心配が。
ソースについては、 ふが日記[http://fuga.jp/~densuke/diary/?date=20010820#p07] が参考になります。

■ 関連記事

詳細はこの日の詳細から

以上、14 日分です。

指定日の日記を表示

前月 2020年09月 翌月
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

最近の日記

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