今回のも、タレコミにある2000年6月の事件も、「公開されないようにしたつもりの情報がソフトウェアを操作するだけで見えてしまう」ということですが、以前の Microsoft Office (詳細を失念)には削除したはずの文書の断片がファイルに含まれてしまうという問題もありました。このような文書の断片はソフトウェアを普通に操作しても出てきませんが、それなりに調べれば読めるということのようです。そういうのは、既に公開された中にあったとしても、発見されていない可能性が高いのではないでしょうか。そう考えると、見つかって指摘されているのは氷山の一角ではないかとも思え、恐ろしく感じます。
AC さんとぼくの意見の食い違いは、将来のソフトウェアに関する見通しの違いから生まれていると思います。ぼくの見通しは将来の可能性の一つでしかない、という批判なら甘んじて受けます。
しかし、もし、ソフトウェアはこの先も現在の形のままにしかならないと思っているなら、 Alan Cooper 著、(株)テクニカルコア訳『ユーザーインターフェースデザイン』翔泳社、1996年 [shoeisha.com]を一読することをお勧めします。全章にわたって「ソフトウェアは現在のものよりよくできる」という主張が貫かれています(今手元になくて確認できないのですが、今でも通用する話が多いと思います)。この本を読めば、現在のソフトより少ない注意力や知識しか要求しないソフトウェアもありうるということがわかっていただけると思います。
情報の漏洩 (スコア:2, 興味深い)
今回のも、タレコミにある2000年6月の事件も、「公開されないようにしたつもりの情報がソフトウェアを操作するだけで見えてしまう」ということですが、以前の Microsoft Office (詳細を失念)には削除したはずの文書の断片がファイルに含まれてしまうという問題もありました。このような文書の断片はソフトウェアを普通に操作しても出てきませんが、それなりに調べれば読めるということのようです。そういうのは、既に公開された中にあったとしても、発見されていない可能性が高いのではないでしょうか。そう考えると、見つかって指摘されているのは氷山の一角ではないかとも思え、恐ろしく感じます。
こういう情報漏洩の問題を根本的に解決するような技術革新が、ないものですかねえ(他力本願)。
と、コメントを書いていて、今回の事件を「情報漏洩」と呼ぶことに多少違和感を覚えるのですが、まあ不注意や知識不足によるミスが原因でも情報漏洩は情報漏洩でしょう。
// 毎日新聞の記事の冒頭に と書いてありますが、後続の文章でも使っていない(しかもぼくの好きでない :)略語をわざわざ括弧に入れてまで示さなくても……。
鵜呑みにしてみる?
Re:情報の漏洩 (スコア:1, 興味深い)
コンピューターとか電子化とかってあくまでも、人間の作業の効率化のため使われているんだから、ソフトの使い方が不注意だったと責めるのは本末転倒かと。
#道具に使われてどうする?人間!
でも、そんなこといっていても現実的でないんで、官邸の情報セキュリティー対策 [kantei.go.jp]に「使用ソフトウェアの出力状態の把握」って項目を入れてもらうしかないかなー
それと、こんなところ [cnet.com]で、セキュリティーチェックの項目に追加してもらうと
Re:情報の漏洩 (スコア:0)
Re:情報の漏洩 (スコア:0)
って言うのは編集用で、アウトプットにまでそんな情報入れる必要は無いと思われ。
いちいち、アウトプットに編集過程情報が含まれていないかチェックしないといけないのは、非効率だと思われ
Re:情報の漏洩 (スコア:0)
そういう意図でアウトプットしてるユーザにはね。
#俺もいらんし。そんな情報。
ただ、自分が使うためだけに作られてるソフトじゃないんだから、
「ソフトの使い方が不注意だったと責めるのは本末転倒」
というのはどうかと思うんですよ。
Re:情報の漏洩 (スコア:1)
>ないものですかねえ(他力本願)。
利用者の「気持ちを自動的に判断」する仕組みが必要になるかと(^^;
もしくは「過去の操作から推測して警告」する仕組みとか…。
#MS-Officeにはそんな仕組みが大量にありますね。
それはさておき…。
私好みの解決方法
1.作業者が適切な知識を持つ
2.他の人にチェックして貰う(紙では無く(^^;)
業界(?)的な解決方法
1.「なんちゃら情報発信システム」の開発
2.発信する内容毎に新しくシステムを開発
3.システム毎に操作が違う&互換性に問題
4.それらの業務を統合した…(1へ戻る)
Re:情報の漏洩 (スコア:0)
> ないものですかねえ(他力本願)。
ほい [nec.com]。
Re:情報の漏洩 (スコア:1)
しかし、研究者がよい研究をしても、それが一般に使われるようになるためには、ソフトウェア開発の技術者の側にも新しい動きが必要だと思うのです。
そのような動きのことを「技術革新」という言葉で表現したかったのです。わかりにくくてすみません。
ところで、ぼくは今「技術者の側」と書きましたが、このように「研究者の側」と「技術者の側」という二者が存在するという考え方では、状況を単純化しすぎているかもしれません。研究者であり同時に技術者でもある人がいるからこそ、研究が実用化されていくのかもしれないと思います。
鵜呑みにしてみる?
Re:情報の漏洩 (スコア:0)
Re:情報の漏洩 (スコア:0)
この事件の原因は、こうした事態にまで知恵がまわらない
愚かな人間が個人情報を扱っていた、という人事の問題。
Re:情報の漏洩 (スコア:1)
ただ、どこに対して反論されているのかが今一つよくわからず、どうも誤解されているような気もするので、 #100947 [srad.jp] の補足を書きつつ少し #101210 [srad.jp] への再反論を試みます。
まず、ぼくは「今回の事件の原因はソフトウェア技術の未熟さにだけあって県にはない」とは思っていません。その点をわかってください。
ぼくは、情報漏洩の心配のないソフトウェアを実現するための技術革新が今すぐ起きるだろうとは思っていません。
言うまでもなく、情報漏洩の心配のないソフトウェアが出てくるのを待つ、というのではこの事件の解決になりません。技術過信とはそのような態度のことを指していると思います。何年か何十年か後にはそれで解決するかもしれませんが、今目の前にある問題を解決するのに未来の技術革新にすがっても仕方がありませんよね。
しかし、目の前の問題を解決する手段を考えるのとは別に、 #100947 に書いたような未来の解決手段を考えることにも価値があります。未来の技術革新にすがっても意味がありませんが、未来の技術革新を想像したり望んだりすることは意味がないどころか、ある意味、技術の進歩になくてはならないステップです。
さて、ぼくが「情報漏洩の心配のないソフトウェアを生む技術革新」が起きてほしいと思う理由は、ユーザの注意力と知識に大きく依存している現在のソフトウェアのあり方が望ましくないと考えているからです。これも技術過信になってしまうのでしょうか。
ぼくは、本来コンピュータはユーザを楽にするためのものであり、ソフトウェアはユーザに注意力や知識を要求するべきでないと考えています。「本来のソフトウェア」を生むような技術革新が(そのうち)起きてほしいという思いがあって、 #100947 を書いたのです。
鵜呑みにしてみる?
Re:情報の漏洩 (スコア:1, すばらしい洞察)
ソフトウェアに多様な機能が存在する限り、その機能を理解していなければ、想定外の事故が起きる。このことはどうやっても、技術革新などで解決できるものではない。警告や説明などによって軽減できるかもしれないが、注意力に依存することは間違いない。
Re:情報の漏洩 (スコア:1)
しかし、もし、ソフトウェアはこの先も現在の形のままにしかならないと思っているなら、 Alan Cooper 著、(株)テクニカルコア訳『ユーザーインターフェースデザイン』翔泳社、1996年 [shoeisha.com]を一読することをお勧めします。全章にわたって「ソフトウェアは現在のものよりよくできる」という主張が貫かれています(今手元になくて確認できないのですが、今でも通用する話が多いと思います)。この本を読めば、現在のソフトより少ない注意力や知識しか要求しないソフトウェアもありうるということがわかっていただけると思います。 多様な機能を搭載したソフトウェアをデザインするとき、ユーザがすべての機能を理解していなければ重大な事故が起きるようなデザインをしていてはよくありません。
また、「機能を理解する」際の理解のレベルにはいろいろがあります。機能がどう実装されているかをユーザに理解してもらうことは困難ですが、実装の方法とは別の方法で理解してもらえば済むことが多いです。ソフトウェアをデザインする際には、ユーザにどう理解してもらうかを考えて、ユーザをその理解に誘導できるようなデザインをするのが望ましいです。 現在のソフトウェアではユーザに注意してほしいときに警告を表示することがよくありますが、警告の使いすぎによってユーザになかなか注意を払ってもらえなくなっています。ユーザの注意力には限りがあるので、警告はここぞという場面でのみ使うべきです。
説明は警告とは違いますが、やはりあちこちで説明を読まなければならないようなソフトウェアではユーザは注意力を使い果たしてしまいます。
ユーザに簡単に注意を払ってもらうためにアイコンを使うことがあります。文字を使うよりも効果的だと思いますが、アイコンも使いすぎれば注意を払ってもらえなくなります。例えば、 Windows にある程度慣れたユーザは、感嘆符の付いたダイアログボックスを見ても感嘆符にあまり注意を払いません。
ソフトウェアによって重大な事故が起きないようにするには、ソフトウェアをデザインする際に、ユーザがどのようにソフトウェアを理解して使うかをよく考える必要があります(デザイナの考えが正しいかどうかを確認するため、デザインの過程でユーザテストというのがよく行われます)。また、ユーザの注意力に限界があることを理解する必要があります。実装と異なる理解をしてもらうためにユーザを誘導する方法も習得する必要があります。
紹介した本には、ユーザに注意力をあまり要求しないようなソフトウェアをデザインする方法が書かれています(どうしてそういうデザインがいいか、という話も書かれていたと思います)。
鵜呑みにしてみる?