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

■1さるくガイドPDF版[電子書籍][desire] このエントリーをはてなブックマークに追加

最近、龍馬ブームで観光客が増えている長崎だけれども、長崎が行っている感心な提案に さるく[http://www.saruku.info/index.php] がある。
さるくは長崎弁で「あるきまわる」と言った様な意味で、長崎のまちをより楽しむために、歩き回りましょうと言った様な提案で、コースガイドパンフレットが用意され、またボランティアのガイドもあり、長崎をより楽しめるようになっている。 まさに、観光地のソフトウェアによる魅力アップである。
さて、このさるくガイドだが、A4見開き4ページの構成で、コースごとにコースマップが作られており、感心なことに ダウンロード[http://www.saruku.info/coursemap.html] できるようになっている。
これをDesireに入れておけば、ちょっと時間が空いた時に、長崎探索ができてすばらしい。 ただし、元が印刷向けの高品位なPDFファイルなため、そのままでは扱いが辛いかも知れない。

■ 関連記事

詳細はこの日の詳細から

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

■1自己展開実行ファイルはウイルスと区別が付かない[セキュリティ] このエントリーをはてなブックマークに追加

「高度に発展した科学技術は魔法と区別が付かない」は、クラークの第三法則。
Happy99[http://www.ipa.go.jp/security/topics/ska.html] の昔から、 「メールに添付された実行ファイルは、たとえ知り合いからのものであっても実行してはいけない」というのは、半ば常識になっていると思っていたのだけれども、時代は大きく変わりつつある様だ。

Happy99.exe:

Happy99.exeは1999年に大流行 *1 したウイルスで、感染するとユーザーが新規メールを送信するたびに自分自身を添付したメールを送信する。
受信者からすると、直前にメールを送ってきた知人が添付ファイルを送ってくるので、 「添付を忘れたのだろう」と思って開くと花火が打ち上がって感染。という仕組みだ。
このウイルス流行以前は、今日ほどにメールがウイルスの感染ルートになるとは考えられて いなかったが、「知人からの添付ファイルと思って油断する」という心理的な隙を突く方法で、 信用できない実行ファイルを実行させてしまうという方法によって、大ブレイクした。
このウイルスの流行を機に、「メールに添付された実行ファイルは、たとえ知り合いからのものであっても実行してはいけない」 という常識が生まれた筈だ。
このため以降のウイルスは、「実行ファイルを実行ファイルに見えない様にする」「勝手に実行させる」 という方向で進化を続けることになる。

実行ファイルを実行することはパソコンを自由にさせること:

実行ファイルを実行することは、その実行ファイルにパソコンを自由にさせることである。 実行されたプログラムは、ディスクをフォーマットすることもできるし、 ウイルスを仕込むこともできる。もちろん、スパイウェアをインストールすることもできる。
ひょっとすると、秘密鍵も盗まれたかも知れないし、ルート証明書も改竄されたかも知れない。
信用できない実行ファイルを実行した瞬間に、そのパソコンは信用できないパソコンになってしまう。 複雑なパスワードを使っても、生体認証を使っても、ファイヤーウォールに守られていても、 利用者が使っているパソコンが情報を盗み出していては何にもならない。
一度でも信用できないプログラムを実行すると、セキュリティは根底から崩壊する

自己復号暗号化:

4月1日に施行された個人情報保護法の影響や続発する情報漏洩事件の影響か、 情報漏洩対策が急速に進んでいる様だし、対策製品も多く出ている。情報漏洩対策特需とも言える状況にある様だ。
その中に、「メールの添付ファイルで情報が漏洩する」点に注目した製品があるのだが、 対策のために「自己展開暗号化」をセールスポイントあるいは機能としている製品がいくつも存在する。
代表的な製品をいくつか掲げる。
ここに掲げた製品に特に問題があるわけではないし、ここで指摘する問題を持った製品は他にも存在するかも知れないししないかも知れない。

圧縮・解凍・暗号 ZELDA for OFFICE[http://irtnet.jp/ct/prod/ashuku-kaitou2.html]:

・自己解凍形式作成機能
解凍に専用のソフトウェアを必要としない圧縮ファイルを作成することが可能です。 不特定多数のお客様へ向けてのファイル配布などに大変便利です。 自己解凍形式には、パスワードを設定することも可能です。

秘文 AE MailGuard[http://hitachisoft.jp/hibun/product/ae_mg.html]:

【添付ファイルの自動暗号化】
添付ファイルを自動的に、 自己復号型暗号化ファイルに変換します。

AutoPass[http://www.vector.co.jp/vpack/browse/pickup/pw3/pw003271.html]:

すると指定したファイルが 実行形式のものに変換される。この暗号化したファイルを起動しようとすると、ウィンドウが開いてパスワードが要求される。これを正しく入力しないと、中身のファイルは入手できない。

WinSafe for TOSHIBA[http://www3.toshiba.co.jp/peripheral/security/point/sec_08.htm]:

自己復号型暗号方式で暗号化されたファイルは、受け取った相手がWinSafeをインストールしていない場合でも、 受け取った暗号ファイルをダブルクリックし、電話などであらかじめ連絡し、決めていた暗証キーを入力するだけでファイルを復号化することが可能です。

ファイルセキュリティLE[http://www.rakuten.co.jp/worldmart/525908/526681/]:

ファイルは自己解凍形式(.exe)でも暗号化できます。 その場合は受信者がWindows環境であればソフトは不要です。 受け取ったファイルにパスワードを入力すればそのまま開くことができます。

自己復号暗号を使うとこうなる:

これらの機能を使ったメールでの添付ファイルの受け渡しは概ね以下の様になるだろう。
From: 知人 何某 <shiriai@example.com>
Subject: 例の件

資料です。

--
取引先株式会社 知人 何某

添付ファイル:XXXX.exe
受信者は、予めパスワードを教えてもらっているか、電話を架けて聞くか、 ひょっとすると、対策ソフトを導入したから安全だと思って、
From: 知人 何某 <shiriai@example.com>
Subject: Re: 例の件

パスワード:password

--
取引先株式会社 知人 何某
として別便で送られて来るか、
From: 知人 何某 <shiriai@example.com>
Subject: 例の件

資料です。
PASS:password

--
取引先株式会社 知人 何某

添付ファイル:XXXX.exe
等という運用になっているかも知れない。 パスワードをどうやって安全に送るかはこれはこれで大問題なのだけど、 ここではもっと大問題に触れたいので深入りしない。
問題はこのファイルを受け取った方である。

セキュリティのための実行ファイルだから実行しても良い?:

知人から実行ファイルが送られてきて、これはセキュリティのためだという。
実行ファイルの添付はメールサーバでフィルタリングする様にしていた会社も、 取引先がこの手のソフトを導入したので、 「セキュリティのために必要」ということで、フィルタリングを解除することにした。
取引先がセキュリティを強化するためにツールを導入した途端、
BANNED CONTENTS ALERT
Our content checker found
banned name: .exe
in email presumably from you (<shiriai@example.com>), to the following recipient:
-> kei@nantoka.com

Delivery of the email was stopped!

The message has been blocked because it contains a component
(as a MIME part or nested within) with declared name
or MIME type or contents type violating our access policy.
等というメールを送って、メールを受け取らなくなってしまったのだ。
大事な取引先のメールを「ウチのポリシーに合わないから」と言って拒否してしまったものだから、メールサーバの管理者は営業部長に呼び出されてつるし上げにあった。
以前は、「メールに添付された実行ファイルは、たとえ知り合いからのもので あっても実行してはいけない」ルールだったのだけれども、 セキュリティのためだから実行しても良いことになった。

どうやってウイルスに気づくのか:

こういう状況で、Happy99.exeの様なウイルスが送られてきた場合、 どうやってそれをウイルスと見破れば良いのだろうか。
ある製品は 「改竄検出機能」を備えており、改竄された場合には警告を発する*2 という。 最近はウイルスフィルタがあるから大丈夫? 署名やパスワードがあるから大丈夫? *3

情報漏洩対策のためには自己展開暗号化:

200X年。世の中では、もはや情報漏洩防止のために添付ファイルは自己展開暗号化形式で 送るのが当たり前になりつつあった。
この種のソフトを導入していない企業とは怖くて取引お断りだね。
という様な事が言われて、むしろメール本文は漏洩する可能性があるから、 添付ファイルでやり取りすることも推奨される様になっていた。
From: 知人 何某 <shiriai@example.com>
Subject: 例の件

password

--
取引先株式会社 知人 何某

添付ファイル:XXXX.exe
の様に、暗号化されたファイルのみをやり取りすれば、たとえメールが漏洩しても、 内容が漏れることは無くなったのだ *5

進化するウイルス:

そんなある日、困ったウイルスが世の中に蔓延した。
感染すると、
  • 感染者の署名とメールアドレスを使って
  • ランダムなパスワードで
  • マイドキュメント内の.xls, .docファイルをランダムに
  • そのファイル名のタイトルで
  • アドレスリストのアドレスに無作為に
送りつける動作をするのだ。
届いたメールは以下の様になる。
From: 知人 何某 <shiriai@example.com>
Subject: 顧客先別四半期売上

7jhd8qkjwd

--
取引先株式会社 知人 何某

添付ファイル:w89hq.exe
これをいつもの様にクリックすると、パスワードを聞かれて、 「顧客先別四半期売上.xls」が出てきたが、どうも自分の会社には関係ない資料の様だ。
当然、 この瞬間には既に感染してしまっていて、マイドキュメントの中の「営業先顧客情報.xls」が十数社に送信されているのだけど、これに気づくことはないし、 スパイウェアが組み込まれた事にも気づかない

自己展開実行ファイルはネット社会全体を危うくする:

これはあくまで架空のストーリーだが、自己展開実行ファイルが普及した頃に こういうウイルスが作られると、大変な被害が発生することは間違いない。
この架空の社会は、どこで間違ってしまったかというと「セキュリティのため」と称して、 「メールに添付された実行ファイルは、たとえ知り合いからのものであっても実行してはいけない」 という原則を曲げたところだ。
架空のストーリーの中の送信者は、 パスワードの運用もいい加減な「暗号化」のために、自己展開実行ファイルを送って、受信者のセキュリティレベルを低下させてしまっている
安全そうに見えるガラクタを使うことによって、使わないよりも悪い状況を作ってしまったのだ *6

メールでの安全な添付ファイルの受け渡し:

  • 安全な暗号化手法を使っていることが客観的に確認できるソフトを使うこと
  • 暗号化/復号化ソフトをお互いに導入できること
  • 安全な鍵配布が行えること
こういったことを考えると、GnuPGを使うのは良い選択の筈だ。
共有鍵を使うのであれば、ZIPパスワードも選択できるかも知れない。
少なくとも、 「受信者が送られてきたファイルを実行する以外に展開する方法がない」方法を使ってはいけない

自己展開形式のメールは親切か:

何らかの圧縮形式を使った場合に、相手が展開環境を持っていない可能性を考慮すると、 自己展開形式で送った方が親切ではないかと考える場合がある。
相手が展開環境をインストールしていなくても、実行すれば展開できるからだ。
もう一歩進めて、自己展開形式であれば、どういう独自の圧縮方法でも展開できるから、 展開ツールを配布する必要がないということになる。
いずれも誤りだ。
受信者が十分な知識を持っている場合。メールで送られてきた実行ファイルを実行するのは、 非常に危険なことだと理解しているから、既に導入されているか、 信頼できるルートで入手して導入した展開ツールで展開しようとするだろう。
この際、拡張子がexeであると、圧縮に使用したツールが分からないために、 展開ツールに何を使ったらよいかを分かりにくくさせてしまう。 使用している環境によっては、うっかり実行してしまうリスクもある。
受信者が十分な知識を持っていないか持っていないと想定される場合。 メールで送られてきた実行ファイルを実行する様に促すこと自体が、相手のセキュリティに関する意識と対策レベルを下げさせることであり、許されることではない
展開ツールが配布されていない場合。そのファイルを安全に展開する方法は無いということである。
いずれにせよ、 自己展開形式が許されるのは、そのファイルを受け取るまでに改竄が行われていないということを送信側が保証でき、受信側がその事を確認できる場合に限られる
この場合、受信者は送信者の保証の下に、そのファイルを信用して実行することになる。
例えば、自分用に自己展開書庫を作っておく場合や、CD-Romで配布する場合、GnuPG等で署名を付けて送信した場合は、送信者(自分の場合もある)を信用して、実行ファイルを実行している。
「改竄が行われるかも知れないメール環境で、改竄対策のために実行ファイルとして送信する」のは自己矛盾だ。

自己展開実行ファイルを区別するウイルスフィルタの可能性:

ユーザーが実行して、しかもパスワードを入力して展開されるウイルスは、 シグネチャでの検出が非常に困難になるだろう。
起動部に、バッファオーバーフローやOSのセキュリティホールといった脆弱性を用いないため、 この部分に特徴を見いだすことが困難である。
ペイロードはその個体毎にランダムなパスワードで暗号化されているので、 一定のシグネチャで検出することはできない。
メール本体へのパスワードの記載方法と、MIME化等の特徴で検出される可能性はあるが、 作者がメタモーフィック化を意識した上で、特徴部分を残さない様に十分に注意して作成した場合、 理論的には、実際に展開してみないと検出できないウイルスを作成することが可能に思える。
「自己展開実行ファイルはウイルスと区別が付かない」と覚悟しておいた方が良い様に思う。

自己展開実行ファイルを使うセキュリティ製品:

こうやって考えると、自己展開実行ファイルを使うセキュリティは、 むしろその危険性が大きいものの様に思えるが、これらの製品を供給している側は、 この様な危険性にどの様に対応しているのだろうか。
メールで送られてきた実行ファイルを実行することに危険性があるということは理解しているはずだ。そういう危険性を考慮せずにセキュリティ製品を供給しているということがあるだろうか。
危険性を承知しているのであれば、 自己展開実行ファイルを作成する機能は、むしろ搭載してはいけない機能では無いか。
あるいは、これらのセキュリティ製品は「送信者側が対策していますという姿勢を示すためのものであって、受信者が危険にさらされるのは問題ではない」と考えているのだろうか。
*1: 2000年バージョンは、Happy00.exe。
*2: もちろん、その実行ファイルは本物の暗号化ファイルでなければならないし、警告されるのは偽物かも知れない実行ファイルが実行された後である。偽物だったらもはや手遅れだ。偽物が自分は偽物だと警告することは考えにくい。
*3: 新しいウイルスは検出できない場合もあるし、後述するように、この手のウイルスに対応するのはウイルスフィルタ側も困難を強いられるだろう。
ウイルスは署名を付けないだろうか。日本語のSubjectを書かないだろうか。日本語の本文を書かないだろうか。
*4: ちなみに、この製品は自己解凍書庫では無くzip形式の書庫を作る点で、受信者の環境は安全だ。
*5: 受信者に成り済ましてパスワードを入力するのは、不正アクセス禁止法で罰せられる。もちろん、悪い冗談だ。
*6: ここで掲げたソフトがガラクタだと主張しているわけではない。使い方によってガラクタ以下になると言っている。

■ 関連記事

詳細はこの日の詳細から

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

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

1532 マルチモニター:

パソコン新調に合わせてマルチモニター環境に。
マルチモニター

■ 関連記事

詳細はこの日の詳細から

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

■1 住民基本台帳ネットワークシステム[http://www.soumu.go.jp/c-gyousei/daityo/][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

一次情報元として掲げておきます。 結局、使い方・実装・運用でのヒューマンファクターが大事だと思います。

ICカード標準システムの概要[http://www.soumu.go.jp/c-gyousei/daityo/pdf/juki_card_04.pdf]:

こんな用途に使っても大丈夫かっていう用途もある気がします。 個人的には、図書館に利用するのは非常に注意が必要だと思います。

長野県個人情報保護審議会第1次報告についての考え方(参考資料2)[http://www.soumu.go.jp/c-gyousei/daityo/pdf/nagano_03.pdf]:

「スマートカードだから安全」の説明

「住民基本台帳ネットワークシステム」の概要[http://www.lasdec.nippon-net.ne.jp/rpo/rss/system_gaiyo/02sec2.pdf]:

ネットワークの構成についてはこのファイルが参考になります。

個人情報保護のための施策[http://www.lasdec.nippon-net.ne.jp/rpo/rss/system_gaiyo/02sec5.pdf]:

セキュリティ対策について

ICカード標準システム導入検討の手引き 第1.0版[http://www.lasdec.nippon-net.ne.jp/rdd/icc/handbook/handbook.pdf]:

標準システムでできること

平成12年度 電気保安統計[http://www.nisa.meti.go.jp/text/denanka/12hoan-tokei/12hoan-tokei.htm]:

停電時間や影響範囲を事故原因、事故の起きた個所別に統計した資料。
停電というセキュリティホールへの対策を考えるための資料として。

■ 関連記事

■2 HTMLメールマガジンをどうするか[http://d.hatena.ne.jp/HiromitsuTakagi/20030606#p1][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

htmlメールを悪用されるとイヤだな[http://www.nantoka.com/~kei/diary/?200212b&to=200212201#T200212201] という話は以前から心配していたのですが、絶妙過ぎるタイミングで、biglobeから 「【 BIGLOBE 】 HTML形式でのお知らせメール配信開始のご案内」とかいうメールが来ました。
http://ct.biglobe.ne.jp/Key=nnnn.XxXX.X.XXXXXX
(nは、数字。Xはアルファベット大文字。xはアルファベット小文字)
みたいなリンクがたくさん入っていて不安になります。
 以下のメールを頂きました。

On Fri, 06 Jun 2003 21:30:55 +0900 (JST)
BIGLOBE RM事務局 <rm1@ct.biglobe.ne.jp> wrote:

> お客様各位
> 
>  平素よりBIGLOBEをご利用いただきましてありがとうございます。
>  BIGLOBE RM事務局です。
>  本日は、BIGLOBEからのメールに関するお知らせをお伝えするため、
>  ご連絡を差し上げました。
> 
 (中略)
>  今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願いいたします。
> 
> ──────────────────────────────────────
>  本メールに関する問い合わせ先:BIGLOBE RM事務局  rm1@bcs.biglobe.ne.jp 
> ──────────────────────────────────────
>   BIGLOBEで困ったときには・・まずご利用ください
>   http://support.biglobe.ne.jp/help/kaiketu/index.html 
> ──────────────────────────────────────
>       ご案内したメールのクリック情報を、お客様へのサービスを向上する
>                    ためにご利用させていただいております。


> 本メールに関する問い合わせ先:BIGLOBE RM事務局  rm1@bcs.biglobe.ne.jp
 とございますので、問い合わせさせて頂いております。
 より適切な問い合わせ先がございましたら、ご連絡ください。

 何点か質問がございますので、ご回答頂きますようにお願いいたします。

On Fri, 06 Jun 2003 21:30:55 +0900 (JST)
BIGLOBE RM事務局 <rm1@ct.biglobe.ne.jp> wrote:

>  ※BIGLOBEをご利用いただいているみなさまのうち、
>    BIGLOBEからの「お知らせメール」の「HTMLメールを受け取る」
>   設定になっている方にお送りしています。

 私はかなり長期間に渡って、biglobeを使用しておりますが、この設定を
行った記憶がありません。
 「お知らせメール」の「HTMLメールを受け取る」と設定しているとの
ことですので:

1. いつどのようにして設定したのか分かるようであればお教えください。
記憶を辿るのに役に立つと思います。

2. 御社のサービスについて私自身がどのように設定しているかを私自身が
確認して、修正する方法をお教えください。

3. 
>    http://ct.biglobe.ne.jp/Key=nnnn.XxXX.X.xxXxxx
>    http://ct.biglobe.ne.jp/Key=nnnn.XxXX.X.XXxXxX
>    http://ct.biglobe.ne.jp/Key=nnnn.XxXX.X.XxXnxX
>    http://ct.biglobe.ne.jp/Key=nnnn.XxXX.X.XnxnnX
>    http://ct.biglobe.ne.jp/Key=nnnn.XxXX.X.XnxxxX

 の様な文字列がありますが、これは何でしょうか。

4. このURLは各々の利用者に対して異なる文字列を付与しているのでしょうか。

5. 異なる文字列を付与している場合、これは個人を特定できる情報を含んでいないのでしょうか。

6. 異なる文字列を付与している場合、私のどのような情報が御社に送信されるのでしょうか。

7. このURLが個別にをクリックしたという事実は、御社側に記録されるのでしょうか。

8. もし記録されるとすれば、その情報はどのように管理されるのでしょうか。

9.
>       ご案内したメールのクリック情報を、お客様へのサービスを向上する
>                    ためにご利用させていただいております。

 この文言がありますが、どのように利用されるのでしょうか。
 上記の文言を了解していたという前提で、私がクリックしたという情報を
無制限に利用することに了解したと判断される可能性がありますでしょうか?

 上記、ご回答頂きますようにお願い申し上げます。

とか問い合わせ中。

■ 関連記事

■3「萌え」はバーチャル化した愛である[テーマ]<< 前の記事 このエントリーをはてなブックマークに追加

その内、まとめたい。
  • 人間関係がバーチャル化しつつある
  • リアルとバーチャルの境界を超越
  • 愛情は注ぐものである
  • 人間関係は希薄化しているが注ぐべき愛が減ったわけではない
  • 愛情を受け入れてくれる対象が必要
  • リアルの相手に拒絶される心配
  • 愛情を受け入れてくれそうな対象に「萌え」
とかなんとか。

■ 関連記事

詳細はこの日の詳細から

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

■1 joker.com 世界一安いドメイン?[https://joker.com/domain/index.html?lang=EN]次の記事 >> このエントリーをはてなブックマークに追加

ここ[http://club.h14m.org/kenji/diary/?200006a&to=200006052#200006052] とか ここ[http://www.domainbird.com/] とかで読んで、気になっているのですが、レジストラの変更ってできるんでしょうか。
あるいは、レジストラが倒産とか撤退した場合の、ドメイン名の扱いって、 どうなるんでしょうねぇ。

■ 関連記事

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

どなたかの日記で読んで、うまい例だと思った文脈に「テレビを配れって言ってるんじゃない」 っていう話がありました。
地域でのインターネットの利用を普及・発展させるには、 行政としてどう取り組んだら良いかという会合に呼ばれていたりするんですが、 未だにディジタルディバイドを作っちゃいけない(それは正しい)、 アクセス料金が高いから普及しないのではないか(確かに地域格差はあるが)、 とかいう議論から、アクセス端末を配って、 無料プロバイダをやればなんていう意見が出て来たりするのは、 やっぱりおかしい気がする。 行政の無料プロバイダのせいで、アクセスインフラが悪くなった地域もあるし、 そもそも税金を使って民間企業の経営を圧迫してどうするという気がする。
反対する分かりやすい例としていいなぁと思ったのです。 で、
「でも、携帯電話はタダ同然で配って配布して急激に普及したでしょ」
うーん。これもイヤなビジネスモデルなんだけどなぁ。 普通の人は、携帯端末がタダ同然で手に入る今が幸せなのかな。 お金きちんと払って良いから、 こんな[http://www.nokia.com/phones/9110/index.html] 端末が色々売ってるほうが幸せ。

ネタもと:

見つけました。 Kuchikiさんとこ[http://www.tls.org/~kuchiki/d/d200006a.html#04-2] でした。
% cd /.u3e/squid/cache
% grep -aR 'テレビ.*配' *
とか凶悪な事を。
日記専用検索エンジンとかないかな。

squidのcacheをnamazuで検索[http://mylab.ike.tottori-u.ac.jp/~mijosxi/1999/12_sqnmz.html]:

というページをメールで教えていただいた。TNXです。 確か、namazuのMLにも流れていた気がしたのですが、見つけられないでいました。

野望:

自分に入ってきた情報を何でも全て代わりに覚えててくれて、 検索を実現できると夢のようだけど、テキストの電子情報に限れば、 今の技術で十分実現できそうな気もする。
テキストに限った電子情報摂取量って、数メガ〜数十メガバイト/日程度の様に思うので、 10GBもあれば1年分の情報が保存できる計算になる。

日記専用検索エンジン[http://yar-3.net/d/?20000608&to=200006084S6#200006084S6]:

はいつかやりたいと 日記バード[http://www.nantoka.com/~kei/nb/] 作ったときから思っているのですが、5分ごとに最新の日記を検索! っていうのを目指すと資源の消費はすごそうですね。

■ 関連記事

■3 sky.pl series[http://rie.h.kobe-u.ac.jp/~ohkubo/script.shtml]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

いまさらなんだけれども、sky.plを導入してみようと思ったり。
本当に便利に使うためには、通常のアドレスで受けたメールを全部転送してしまうのが良いのですが、 procmailで分類しきれないメールがまだまだたくさんあるので、 先にメールのフィルタリング技術を確立しないとですね。

メールのフィルタリングは:

メーリングリストを先に振り分けておいて、ToにもCcにも自分のアドレスがなければ、 振り分けてしまうというのが良くある方法なのだけれども、 いわゆる各位宛てで送られてくるメールの中には必要なものがあるので困る。
今のところ、ToにもCcにも入っていなくて、jpドメイン発で無いものは、 「暇な時読む用フォルダ」に落とすようにしているのだけれども、 これでは不要なメールをはじききれない。
これ以上はコンテンツを分析しないと難しいでしょうね。

■ 関連記事

■4 続・squidのcacheをnamazuで検索[http://www.nantoka.com/~kei/diary/200006.html?to=200006082S2#T200006082S2][freebsd]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

やってみました。
[Base]
Date: Thu Jun  8 17:38:42 2000
Added   Files: 5,319 files
Deleted Files: 0 files
Updated Files: 0 files
Total   Files: 5,319 files
Size: 82,560,754 bytes
Keywords: 381,487 words
Wakati: /usr/local/bin/kakasi -ieuc -oeuc -w
Perl Version: 5.00503
Namazu Version: 1.3.0.11
System: freebsd
Time: 4725 sec.
こんな感じにインデックスを作って、ひみつのディレクトリにindex.cgiを設置。 素晴らしい!

おかげで:

ずっと「どこかで読んだ」と思いつつ探していたページが見つかりましたよ。 タイトルが分かればすぐ分かるページなのですが、 魔法のおなべ[http://cruel.org/freeware/magicpot.html] で、ここの中にある、 間接販売価値モデル[http://cruel.org/freeware/magicpot.html#9] の分類を探していたのでした。
読んで見たのだけれども、僕の動機にピッタリの表現はなかった。

■ 関連記事

■5 続・オープンソースの盗用[http://www.nantoka.com/~kei/diary/200006.html?to=200006072#T200006072][ぐる]<< 前の記事 このエントリーをはてなブックマークに追加

私が 危機[http://www.fastwave.gr.jp/diarysrv/kohgushi/20000608.html#20000608-7] というか心配に思うのは、この問題の広まり方が報道などできちんと扱われないでゆがんでしまうと、
  • オープンソースの心の部分がおざなりに、単に権利問題として扱われたり
  • オープンソースの宣言無視しても(社会的にも)制裁を受けないという前例になったり
  • オープンソースに企業として近づくのは危険だという誤解を生じたり
する可能性があることです。
今のオープンソースの文化というのは、どうも「平和」という感覚に似ているので、 *1 ある種のあやうさがあります。
私自身はBSDスタイルのライセンスが好きで、もし私のところでオープンソースにできるものが開発できたとしたら、 こういう利用のされ方[http://www2.willy.co.jp/~s-tomo/diary/?200006a&to=200006071S1#200006071S1] をされたとしても、それはそれで良い事だと思っています。
いわゆるオープンソースを宣言するために、 色々なライセンス[http://www.gnu.org/philosophy/license-list.ja.html] があります。 各々、目的もルールも違うわけですが、これが守ってもらえるかどうかは非常にあやうい契約です。
例えば、商業組織が作っているソフトウェアのソースを契約に違反して使用したことが発覚した場合、 流用された側が黙っていない限り、それなりの問題になります。 権利を持っている商業組織側は、権利を守るために戦うでしょう。 オープンソースの場合は誰が戦うのでしょうか。
私の主観では、オープンソースをライセンスを無視して流用する方が、 シュリンクラップ契約に違反するよりも罪が重いような気がするのです。
市販ソフトのコピーを販売するのと、 オープンソースプロダクトのライセンスに違反して製品を販売するのは、 後者の方が罪が思い様に思うのです。
だけれども一般的な評価が、 「ソースをタダで配ってるものを使って製品作って何がいけないの?」 なんて事になるのは杞憂ではないのかも知れません。 オープンソースを本当に理解してもらうのには、まだまだ努力が必要な様です。
当面は、 JM5 盗用問題 Watch[http://www01.u-page.so-net.ne.jp/fb3/rey/pax/watch.html] に注目して行きたいと思います。

補記[http://www.nantoka.com/~kei/diary/200006.html?to=200006092#T200006092]:

これを書いた頃、私は「ソースが公開されている=オープンソース」という認識でいました。
*1: ここで平和問題を論じたいわけではないので、 「大切で貴重なんだけれども、日ごろは感謝やそれを守って行く事の大切さを忘れてしまう何か」 に置き換えて読んでもらうとありがたいです。

■ 関連記事

詳細はこの日の詳細から

以上、14 日分です。

指定日の日記を表示

前月 2019年11月 翌月
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