2005年03月11日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 findとrmの競合条件[http://tabesugi.net/memo/cur/cur.html#090855][セキュリティ][freebsd]次の記事 >> このエントリーをはてなブックマークに追加

レースコンディションによるセキュリティホールとして有名な例ですね。
手元の、FreeBSDの/etc/dailyを見たら、
/etc/daily
# This is a security hole, never use 'find' on a public directory
# with -exec rm -f as root. This can be exploited to delete any file
# on the system.
#
#find / \( ! -fstype local -o -fstype rdonly \) -a -prune -o \
# \( -name '[#,]*' -o -name '.#*' -o -name a.out -o -name '*.core' \
# -o -name '*.CKP' -o -name '.emacs_[0-9]*' \) \
# -a -atime +3 -exec rm -f -- {} \;
#
って書いてありますね。みんなが書き込めるディレクトリで、find -exec rm -f をrootで実行するなと。

■ 関連記事

■2 「はかる」って「量る」?「計る」?[http://yar-3.net/d/?20050311&to=200503111S8#200503111S8][ぐる]<< 前の記事 このエントリーをはてなブックマークに追加

最近、 ハトのマークのひっこし専門[http://yar-3.net/puki/pukiwiki.php?%A5%CF%A5%C8%A4%CE%A5%DE%A1%BC%A5%AF%A4%CE%A4%D2%A4%C3%A4%B3%A4%B7%C0%EC%CC%E7%A5%C8%A5%E9%A5%D6%A5%EB%A4%DE%A4%C8%A4%E1] で有名な人のところから。
続・「ソ21.jp」問題[http://www.nantoka.com/~kei/diary/?200502c&to=200502252#T200502252] で触れた話だけれども、日本語には似た概念で同じ読みだけれども違う文字という組み合わせを持つものが多い。多分、国語学で用語があるのだろうけど。
例えば、「はかる」については、「計る」「量る」「測る」あたりは概念類似で文字が違うが同じ読みをする。「収める」「納める」「治める」あたりも同じ様なものだと思う。
恐らく、日本語で「はかる」だったものに漢字文化が入ってから、文字を使って細かい意味を表出することを導入してこうなったのではないかと思っているのだけれども、どういう資料を調べたら、これが裏付けられるのかも見当が付かなくて、そのままになっている。国語学を勉強した人には常識なのかも知れない。
ところで、「計る」は数量や時間、「量る」は容量や重さ、「測る」は面積や速度を「はかる」のだけれども、こういうのを確認するために以前はいちいち辞書を引いていた。これが自動的に出てくるので、最近はATOKを手放せなくなった。

■ 関連記事

詳細はこの日の詳細から

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

■1 ICカードと電子ポスターを利用したマーケティング技術を開発〜産総研発ベンチャーを設立し実用化[http://www.aist.go.jp/aist_j/press_release/pr2005/pr20050310/pr20050310.html][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

ICカードやモバイルデバイスを利用し、ユニークIDとそのIDを取得した場所および時間を手がかりとしてユーザの要求を特定し、適切なサービスを起動するもので、本技術を使用することにより、Suicaに利用されているFeliCa仕様のICカードをはじめ、Bluetooth規格の端末機器や各種ICカード、その他ユニークIDを持つモバイルデバイスを統一的に扱うことができる。

本技術の特長は、個人情報の提供や事前登録などを必要とせずに匿名で利用でき、また既に流通し所有している非接触ICカードを利用可能としたことである。
の話は、 3月11日の日経産業新聞の記事[http://it.nikkei.co.jp/it/newssp/iccard.cfm?i=2005031008205uh] で知った。
ちょうど、 「Suica番号がメールアドレスと結び付けられ始めた」[http://takagi-hiromitsu.jp/diary/20050305.html#p01] の記事を読んだ後だったので、どういう立場で書かれているのか深読みをしていたのだけれども、 深読みに過ぎなかった[http://takagi-hiromitsu.jp/diary/20050311.html#p02] らしい。組織が大きくなると、色々と難しい問題が出てくる様です。
直接関係ないけれども、思いつくヒトは「実施時のセキュリティ問題は置いておいて」システムを提案して、設計するヒトは「問題は運用でカバーすればいいや」と思って設計して、実装するヒトは「問題は設計レベルでカバーされている筈」と思って実装して、営業するヒトは「とにかく安全ですから」と言って売り込んで、運用するヒトは「大丈夫って言ってるんだから大丈夫」と思いこんで運用して、利用者は大丈夫でないものを大丈夫と信じ込まされて使っているという、どこかで聞いた様な話を思い出した。

■ 関連記事

■2 プライバシー問題の解決が難しいのはなぜか〜第8回 コンピュータ犯罪に関する白浜シンポジウム REPORT[http://www.jstage.jst.go.jp/article/shirahama/8/0/8_54/_article/-char/ja/][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

高木浩光@自宅の日記[http://takagi-hiromitsu.jp/diary/20050311.html#p03] から。
Webアプリの欠陥が無くならない原因として、
この種のものが適正な費用をかけずに構築されているのではないでしょうか。即ち、安い構築事業者を使う、安いサービスにアウトソースする、あるいは入札して安いところが落札するとか、これをどう防ぐのかが難しいのです。
という問題を指摘している。これは常々感じるところで、受注者からすると、セキュリティはバグの有無という品質管理の観点と比べてもさらに見えにくい品質なので、ここを落とせば、顧客に見えないところで相当なコストを削減できる性質がある。
ことに入札ということになると、設計上明に要求されていないけれども、実装者の良心として対策すべきことを盛り込んで価格を出せば、必ず負けるという残念な状況がある *1
知らなければ大穴を空けたまま納品してしまえば良いことなので、良心の呵責も少ないけれども、知っていると技術者の良心を取るかお金を取るかという、困った状況に追い込まれる。
入札の場合、お金を掛ければ、つまり最低制限価格を上げれば、極端な安値で落札されることは無くなるけれども、これがセキュリティ面を含めた品質の向上に繋がるかというとそうはならないという問題がある。受注者からすると、同じものを高い金額で納めるだけのことになってしまう可能性が高い。
結局、あくまで入札を使いつつ、この問題を解決するためには、仕様書を作成する段階でセキュリティに関して十分な要件を定義する必要があるし、その通りに実装されたかどうかを第三者が確認する必要が出てくる。
ただ、この場合、設計者は実装者以上に実装に関する知識と考察を要求されることになるので、そこまでやって設計と実装を分離して割が合うのかどうかが新たな問題となるだろう。
もう一つ指摘しておくと、セキュリティは各工程で作り込むものであって、システムができあがってから、何らかの対策をしてセキュリティを確保するということは、大抵の場合、不可能である。
ところが、
「SSLを使っているのでセキュリティは万全です」という認識であったりする
という状況は、冗談でなく往々にして起こる。類似の例に、
「ベリサイン社の証明書を取得しており、セキュリティは万全です」
というものもあるし、
「ファイヤーウォールを導入したのでセキュリティは万全です」
や、
「IDSを設置したのでハッカー対策は万全です」
というものもある。セキュリティを確保してくれる魔法の箱はない *2
*1: 金額の乖離は、設計者が仕様書に盛り込まなかったセキュリティ上の要件と、実装者が意識している潜在的なリスクに比例する。
*2: 良く知られた攻撃に対して、アプリケーションレベルで対策してくれる箱を作ったら売れるだろうと夢想したことはあるが、なかなか難しそうだ。

■ 関連記事

■3 続・「はかる」って「量る」?「計る」?[?200503b&to=200503112#200503112]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■4 IRCnet #組み込み 誕生[http://slashdot.jp/journal.pl?op=display&uid=4374&id=234635][IRC]<< 前の記事 このエントリーをはてなブックマークに追加

kei6氏(nantoka.comのひと)も組み込みをやってるそうな。
FreeBSDサーバ管理者だとばかり思ってたので、意外ですた。
私の中では、セキュアプログラミングと組み込みとUNIXは、より低いレイヤのことを考えてないといけないという線で繋がっています。
最近のプログラマは、即戦力に育たないといけませんから、PHPならPHP、JavaならJava、CならCの言語だけの教育を受けて、実戦配備されちゃうことが多いので、パケットやメモリを意識しないプログラマが増えている気がします。
セキュアなコードを書こうと思うと、例えば、「?ID=abc%d」を受け取って、「'abc-31491'は無効なIDです。」と表示されるのはとてつもなくマズイだろうということにピンと来ないといけないのですが、上のレイヤだけの教育では、この辺りが身に付いて来ない気がします。
日本の将来を考えると、この辺りの問題はとても深刻だと思うのですが。

■ 関連記事

詳細はこの日の詳細から

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

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

■ 関連記事

■2 小泉内閣メールマガジン[http://www.kantei.go.jp/jp/m-magazine/jyouken_ya.html][個人情報]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

個人情報保護法の絡みで、
過去に「サービスA」の提供のためにとして同意を得て収集した個人情報がある。
この度、「サービスA」をより充実させて「サービスA+」とし、名称も変更した。
実際に個人情報を使用する範囲や目的に変更は無いが、収集した際に提示した利用目的に現われる名称とは異なる。
という場合に、以前のサービス利用者に改めて同意を得る必要があるかという相談を頂いた。
これは、お客さんがどう思うかを考えれば答えが出るわけで、クライアントとしては納得できる対応策にたどり着いたので一件落着である。
類似事例を探していて、 「小泉内閣メールマガジン」のご利用条件[http://www.kantei.go.jp/jp/m-magazine/jyouken_ya.html] を見つけた。
登録いただいたメールアドレス等の情報は、「小泉内閣メールマガジン」の配信及び制作以外には使用しません
とあるのだけれども、内閣が変わった時はどうするのだろうか。

■ 関連記事

■3「当社は、お客様からお預かりしている個人情報について、以下の場合、第三者に開示する場合があります。」は、それ以外がないとは宣言していない[個人情報]<< 前の記事 このエントリーをはてなブックマークに追加

なるほど。そう来ましたか。そうですか。それ以外がないと勝手に勘違いしたこっちが悪いということですね。確かに、「場合があります」って書いてあるだけで、それ以外が無いとは一言も書いていないですね。うっかりひっかかりました。
御社のプライバシーポリシーは客を引っかけるためにあるんですか、そうですか。これは不親切じゃないですか、同じ勘違いをみんなするんじゃないですか、とか確認したところ、会社としての正式な回答ではないということなので、しばらく保留。
同じ勘違いをしないように、みなさんも注意。

■ 関連記事

詳細はこの日の詳細から

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

■1メールサーバのディスク変更[freebsd]次の記事 >> このエントリーをはてなブックマークに追加

メールサーバが重いのだけれども、ボトルネックはディスクではないかという気がしたので、ディスク交換で色々あって浮いたディスクで、SCSI化してみる。
dump/restoreでコピーしているのだけれども、imapのファイルが山ほどあるので、ディスクtoディスクでもずいぶんコピーに時間が掛かる様だ。

■ 関連記事

■2 更新頻度が明らかに低下した絵師サイトについて[http://thispage.sakuratan.com/mixi.htm][mixi]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

著作者には、自分のコンテンツを自分の好きな媒体に公開する権利があるわけですが、コンテンツが囲い込まれるのはイヤだったので、mixiに入ってはいますけれども、私の日記は「外部blog」の、ここのままです。
日記サイト運営ビジネスっていうのが成り立たないかなぁということを考えてきて、考えている内に、今や実際色々なビジネスが誕生しているのですが、書き手の立場として、コンテンツを人質に取られるのは嫌だという意識が邪魔をしていた様です。
日記サイト運営をビジネスとして考えれば、逆に、コンテンツを人質に取れるというのはビジネス上非常に有利なポイントな訳ですし、実はこれから日記を書こうという利用者の多くは「コンテンツを人質に取られる」ということを意識しないはずです。
つまり、ビジネスとして考える時に、ビジネス提供側の立場に切り替えができなかったということで、反省となっています。

■ 関連記事

■3 続・findとrmの競合条件[?200503b&to=200503111#200503111][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

「シェルでセキュアなテンポラリファイル!! の巻」[http://www.bsddiary.net/d/200503.html#14] というコメントを頂いきました。
「filter > foo.$$」は、時々、Makefileの中から使いたくなって、危険だと分かってはいるのですが、mktemp(1)使うのも面倒なので、自分専用のtmpに書くようにしていたりします。
/tmpをあえて使わなくても良い時代になったかも知れません。

■ 関連記事

詳細はこの日の詳細から

2005年03月15日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 UFJ銀行を偽装した電子メール詐欺が発生していますのでご注意ください[http://www.ufjbank.co.jp/ippan/oshirase/050315_chuui.html][セキュリティ][フィッシング詐欺]次の記事 >> このエントリーをはてなブックマークに追加

産経新聞社の記事[http://www.sankei.co.jp/news/050315/sha071.htm]
AH0K's Diary[http://www.ah0k.com/diary/d200503b.html#14-3-3] にサンプルがありますが、まともな日本語になっている様です。
日本でも、本格的なフィッシング詐欺時代突入かも知れません。

UFJ銀行を偽装した電子メール詐欺が発生していますのでご注意ください[http://www.ufjbank.co.jp/ippan/oshirase/050315_chuui.html]:

サーバ証明書の確認方法も掲載されているのだから、
暗証番号、パスワード等の重要情報の入力を受付ける場合には、SSLによる暗号化通信を行っております。SSLによる暗号化通信が行われるページのアドレスは「https://」から始まっており、画面の右下(Webブラウザのステータスバー)に鍵のマークが表示されます。鍵マークをダブルクリックしてサーバ証明書を表示し、UFJ銀行のドメインおよび英文組織名が書かれていることをご確認ください。
は、例えば、
暗証番号、パスワード等の重要情報の入力を受付ける場合には、 かならず SSLによる暗号化通信を行っております。SSLによる暗号化通信が行われるページのアドレスは「https://」から始まっており、画面の右下(Webブラウザのステータスバー)に鍵のマークが表示されます。鍵マークをダブルクリックしてサーバ証明書を表示し、UFJ銀行のドメインおよび英文組織名が書かれていることをご確認ください。
鍵のマークが出ていない場合、ここに記載されている以外のドメインおよび英文組織名が書かれていた場合は、お客様の情報を不正に詐取しようとするページだと思われます。至急、当行までご連絡下さい。
等と言い切ってアナウンスした方が良いのでは無いかと思う。「鍵のマークが出ないのはおかしい」「違うドメイン名が表示されるのはおかしい」という認識を持ってもらうのが予防策なのだから。
この方針で行くと、
UFJ銀行を名乗り、不特定多数のお客さまあてにセキュリティーのためと称して本人確認を促す電子メールが配信され、偽装されたホームページからお客さまの重要情報を不正に詐取しようとする事実が発覚しました。 当行とは一切関係ございません。本件は虚偽のページにアクセスさせ、インターネットバンキングの暗証番号や、ご利用のクレジットカードの会員番号・暗証番号などの重要情報を入力させることにより、個人情報を不正に取得しようとするものです。暗証番号などの重要情報を入力なさらないようご注意ください。 当行では、電子メールではこうしたご連絡はいたしておりませんのでご注意ください。
も、「今後もこうした連絡をすることは無い」そして、そういう連絡が来たら疑えとアナウンスすべきだろう。

■ 関連記事

■2 IT商談の“引き合いバブル”,失注の理由をご存じですか[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050313/157370/][IT]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ITソリューションの商談では,ユーザー企業が“当て馬”を使うケースが多い。当て馬とは,発注する気が最初からないにもかかわらず,ユーザー企業が見積もりを取る業者のことだ。発注を内定しているシステム・インテグレータに料金の引き下げ促す手段に使う。また,情報システム部門が発注先の選定理由を経営トップに説明するための“飾り”に使う場合もある。
たしかに、これはたまったものではない。モノの見積もりと違って、ソリューションの見積もりは、それ自体がソリューションの提供だからだ。
あるシステムの見積もりをするには、そのシステムを理解しなければならないし、実現するための要素技術の選定をしないといけない。
各々の工数を出して、リスク係数を掛けて、リスクテイクファクターに利益を含んだ形で、ようやく、受注希望金額が算出できる。
本来はここからが交渉で、もう少しコストを落としたいという事情があれば、例えば、「この技術の開発にコストが掛かっています。将来、システムのボトルネックになるのは分かっていますが、ここは既存の技術で間に合わせましょう。立ち上げ後に、ビジネスが予想以上の速度で拡大したら、改めてここを作り直す費用を確保して下さい。」 等という相談になるのが、理想的な姿で、こういう交渉が可能な様に分析、見積もりするのがITソリューションの見積もりだと思っていた。
つまり、ITソリューションの見積もりは金額だけで比較はできないので、簡単に「合い見積もり」を取ることは本来できない。
けれども、こうやって積算させておいて、A社の書いた積算資料を単価を安く書いたB社に回して、コストを浮かすことができたとかよろこんでいる事例もある様だ。本当はITでそんなことはないのだけれど。
もし、合い見積もりをやるなら、RFPから始めるべきだろうけど、受注側はもっと高コストになる。難しい問題だ。

■ 関連記事

■3個人情報保護法対策詐欺?[個人情報保護]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

個人情報保護法対策をうたった詐欺まがいの商法が横行している模様。
知人から相談を受けたところによると、個人情報保護法を気にもしていなかった様な小規模な事業所を狙って、いかにも国の機関の様な、例えば「内閣府認証の個人情報保護協会」等と名乗って電話を掛けてくる様だ。
  • 4月1日から個人情報保護法が施行されるのはご存じでしたか。
  • 顧客名簿などをパソコンで扱っておられる全ての事業所が対象になります。
  • 対策を行っていないと、罰金や懲役になります。
  • 対策は済んでいますか
  • パソコンは何台お使いですか
という感じで、20万円程度のお金を振り込むと、「個人情報保護対策マニュアルセット」と、(パソコンに導入する)「個人情報保護対策キット」を送ってくるというものらしい。
「罰金や懲役」と聞いて、驚いて私のところに相談してきたのだけれども、それらのものが金額に見合うものなのかどうかは別として、どうもあやしい商売の感をぬぐえないし、そんなの買っただけで対策済みにはならないから、きっと無駄という説明をしておいた。
同じお金を使うのなら、初心者向きの本を買って勉強して *1 、とりあえずウイルス対策ソフトを入れると良さそうだ *2 。あと、シュレッダーも *3
*1: つまり、その程度の認識な訳です。個人情報保護法を初めて知ったみたいな。
*2: つまり、パソコンはその程度にしか使われていない訳です。メールも仕事に使っていないし。
*3: むしろ紙の方がヤバイと。

■ 関連記事

■4 トークンではフィッシング詐欺を防げない?[http://www.itmedia.co.jp/enterprise/articles/0503/14/news063.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

Stressful Angel[http://stressfulangel.cocolog-nifty.com/stressful_angel/2005/03/_315.html] から。
2月17日に3Dセキュア[?200502b&to=200502172#200502172] について書いたのだけれども、この時に「3Dセキュア」の仕組みそのものに問題を感じてやり取りしていた。
某カード会社に至っては、3Dセキュアの仕組み自体を理解していないのか、秘密のはずのトークンが事実上わずか2つに限定されるという運用になっていて、これはこれで問題なのだけれども、トークンを使う認証そのものに穴があるのだから、結果は一緒だ。
「3Dセキュアを使う時は、普通にカード番号を使う時よりも、さらに、利用者はフィッシング詐欺に気を付けないとならない」ということを結論にしておく。

対策されたらお知らせ下さい:

とお願いしたのだけれども、今のところ連絡はないし、対策した様子も無いようだ。

■ 関連記事

■5 HNS 用トラックバック実装[http://www.ku3g.org/negi/diary/?20040508#200405081][hns]<< 前の記事 このエントリーをはてなブックマークに追加

導入したらトラックバックspamに見舞われそうな気もするけど、その対処は対処で学ぶところがありそうだ。というかとにかく導入したい。

導入してみた:

動いている模様

■ 関連記事

詳細はこの日の詳細から

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

■1靴にICタグでバラ色の未来[セキュリティ][ICタグ]次の記事 >> このエントリーをはてなブックマークに追加

昨夜のニュース番組で、 ICタグを靴に取り付けて在庫管理をする三越百貨店[http://bizns.nikkeibp.co.jp/cgi-bin/search/wcs-bun.cgi?ID=337271&FORM=biztechnews] のレポートを放送していた。
「便利だけどもプライバシー問題が」という切り口を期待していたけれども、ICタグのコストが問題で、それは 響プロジェクト[http://itpro.nikkeibp.co.jp/free/NBY/RFID/20031219/1/] で解決されるというバラ色の未来が描かれて終わっていた。
書籍にICタグを入れると、立ち読みする客の行動が追跡できて、マーケティングに威力を発揮するし、靴にICタグを入れると、販売機会を逸したとかこれまで取れなかったマーケティング情報が取れるようになるとか、素晴らしいことばかりだ。
幸い、録画できたのでいずれ続報を。

■ 関連記事

■2 続・UFJ銀行を偽装した電子メール詐欺が発生していますのでご注意ください[?200503b&to=200503151#200503151][セキュリティ][フィッシング詐欺]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

高木先生も 「銀行業界が自治体に苦情を申し立てても不思議でない」[http://takagi-hiromitsu.jp/diary/20050315.html#p01] と題して取り上げている。
警告が出たら「いいえ」を押すのが当然の常識として人々にもともと理解されているはずのところが、昨今では、その常識が崩れつつある。その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対するphishing攻撃の危険性を増大させている。
国や自治体がこの国のPKIをズタボロにしたというのは大げさではない。
インターネットはエンドユーザーがネットワークの一部を支えているという点で、旧来のクライアントサーバ型のシステムと非常に大きく異なる。
クライアントサーバ型システムでは、サービスの提供者側が利用端末までを管理して、閉じたシステムを構成していた。利用端末に至るまでがサービス提供者の責任範囲だから、どういう端末を使おうが、サービス提供者の責任に於いて自由に決定することができる。
イントラネットもこの形体に近い。閉じたシステムなのだから、社内サービスを提供する側が端末側も管理し、責任を負う格好で、オレオレ証明書を導入することも許されるだろう。
インターネットに公開するサービスは事情が違う。端末を運用して、責任を負うのは利用者の側なのだ。あるサービスを利用するために、あやしいルート証明書を導入してしまったら、その端末は信用できない端末になってしまう。これはその端末で利用する全てのサービスに影響を与える。
プラグインを導入するのも一緒だ。信用できないプラグインを導入してしまえば、その端末は信用できない端末になってしまう。これもその端末で利用する全てのサービスに影響を与える。
端末の利用者は、同じパソコンを様々なサービスの利用に使うのだから、信頼できるルールに則って提供される証明書しか受け入れてはいけない。これは安心してネットワークを利用するPKIを構築するために、端末運用者(=利用者)に科せられた責務だ。
一部の行政のサービス提供者は、利用者のパソコンを「ウチの自治体サービス端末」とでも思っているのではなかろうか。
そして、イントラネットを構築する積もりで、利用者に「これを導入しろ、信用して『はい』を押せ」とやっているのではないか。だとすると、これだけ、オレオレ証明書にもプラグインにも、無頓着な作りを看過していることが理解できる。
だとすると、端末で起こる問題にも責任を負う必要が生じるはずだが、一切責任を負わないと宣言しているのはどうしたことだろうか。

自治体が署名したActiveXのバグ:

自治体が署名したActiveXコントロールにバグがあって、情報を盗まれるとか、パソコンがおかしくなって業務に支障が出るとか、そういう形でユーザが被害にあったりすると、訴訟を起こされそうな気がする。
仮に「一切の責任を負いません」と表記したとしても、自治体が提供している行政サービスを受けるために不可欠のものであり、サービスを受けるためには導入が必要だと説明しているのだから、責任を免れない可能性は高い。
そう考えると、ActiveXコントロールが必要な電子自治体システムを構築している自治体は、相当に勇気があると思う。

■ 関連記事

■3 国際化ドメイン名(IDN)のフィッシング詐欺脆弱性についてCENTRが声明[http://日本語.jp/access/phishing_centr.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

「paypаl.com」と「paypal.com」,違いが分かりますか?[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050311/157348/index.shtml] から。
これまでに何度か、「ソ二一.jp」問題と「養老乃瀧.jp」問題として、日本語におけるIDNの運用の問題について取り上げてきた。
日本語.jpのフィッシング詐欺対策に「ソ二一.jp」問題は含まれているのか, 2005年2月21日[?200502c&to=200502213#200502213]
続・日本語.jpのフィッシング詐欺対策に「ソ二一.jp」問題は含まれているのか, 2005年2月25日[?200502c&to=200502252#200502252]
IDN(多言語ドメイン・日本語ドメイン)での"見た目に似た文字列, 2005年3月8日[?200503a&to=200503081#200503081]
この声明が日本語独自の問題に触れていないのは仕方がないとしても、 ITProの記事[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050311/157348/index.shtml] が、
さらにJPRSによれば,IDNを導入した時点で今回のような事態は十分予想されていて,防ぐためのガイドライン――「JETガイドライン(RFC3743)」や「ICANNガイドライン」――を用意しているという。これらに基づいて,IDN登録を運用すれば,多くの場合,今回のような事態は避けられる。
(中略)
実際,JPRSではガイドラインに従った運用をしているので,「example.jp」(すべてASCII)は登録できるが,「exаmple.jp」(ASCIIにキリル文字аが混入)は登録できない。
と、日本語特有の問題に言及していないのは残念だ。

■ 関連記事

■4 市長メルマガにウイルス[http://www.tokyo-np.co.jp/00/sya/20050314/eve_____sya_____004.shtml][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

市広報課は「悪意のある者、あるいはウイルスに感染した方よりメールマガジン配信サーバーあてにメールを送付されたことが原因」と話している。通常、サーバーに外部から返信があっても登録者にメールは送られないが、送信者が市広報課に偽装されていたため、自動的に転送されてしまったという。
このシステム、「秘密の」アドレス宛に特定(市広報課)のFromを付けたメールを送ると、購読者宛に配信するという仕組みになっていた様だけれども、「秘密の」筈のアドレスが、Receivedのfor等の形でヘッダに付いたまま配信されていたか、あるいは全然秘密のアドレスになっていなかったのではないか。
この話、 Webアプリの欠陥が無くならない原因[?200503b&to=200503122#200503122] で触れた話と通じるものがある。
ある程度、メール配信の怖さを知っていれば、「メール配信システムの構築」と言う案件があって積算をする時に、
  • 外部から勝手に配信されることをどう防ぐか
  • いたずらによる登録にどう対応するか
  • エラーメールの処理をどうするか
  • ウイルスの誤送信をどう防ぐか
  • エラー時の特定のMTAの困った挙動にどう対応するか
  • 隠れバウンスエラーにどう対応するか
と言った様なことを最低限気に掛けるものだ。実際、安全なメール配信システムを構築するのは本当に難しい。そういった中で、どこまでは許せるということを考えながら、例えば、
  • ドメイン内部からであることを詐称されない方法で確実に判定する
  • 送信時に何らかの方法でパスワードを確認する
  • フィルタリングして添付ファイル付きメールは配送しないようにする
  • エラーメールを分析する方法を用意する
ということを盛り込んだ仕様を考えて、ある程度のスクリプトを開発することを前提にして積算することになる。
ところが、蓋を開けてみると、Webで入力すると特定のaliasのincludeが書き換えられるだけの仕組みが構築されたりする。発注者が要求したことは確かにできるのだ。
セキュリティのためのコストを当然掛けるべきコストという認識が発注者に広まる必要があるのだけれども、 個人情報保護法でクライアントの意識は変わるのだろうか[http://slashdot.jp/article.pl?sid=05/03/14/0456231]

ウイルスメール配信のお詫びとご報告[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0312mailmaga.html]:

違う。
これは悪意のある者、あるいはウィルスに感染した方よりメールマガジン配信サーバあてにメールを送付されたことが原因です。
第三者から送信されたメールが、メールマガジン配信サーバから配信される仕組みだったことが原因ではないか。これは責任回避だろうか、それとも本当にそう考えているのだろうか。
本当にそう考えているのだとすると、再発防止策があさっての方向に行ってしまうような気がする。

ウイルスメールの配信の経過報告[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0314mailmaga.html]:

非常に気になることがあって、
メールマガジンの配信(毎月5日、20日)については、個人情報の保護を考慮して受取人のアドレスが他の方には分からない方法で行います。
今までは分かったんじゃなかろうね。

■ 関連記事

詳細はこの日の詳細から

2005年03月17日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 [和書]インターネットヒストリー―オープンソース革命の起源[http://www.amazon.co.jp/exec/obidos/ASIN/4900900923/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1][book]次の記事 >> このエントリーをはてなブックマークに追加

読んでるところ。新しい地平を拓くために歴史に学ぼう。

■ 関連記事

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

寿司詐欺[http://yutunapenguin.ameblo.jp/entry-b46a66540b4f0a069ed14cadd93eaa75.html]:

RinRin王国[http://www.pluto.dti.ne.jp/~rinou/index.html#20050316] から。
古典的な詐欺もちゃんと生き残ってるんですねぇ。 似たヤツでは、背広のボタンの位置がってのもありますな。

しかし考えてみると:

500円というのは高いのか安いのか良く分からなくなってきた。 ただ、騙されたと感じた時点で、きっとおいしくなくなるので損をした気分になるのは確かだろう。

http://rss-jp.net/ のページが:

なんかおかしいことになっていますね。あやしげな画面なのであえてリンクしていません。

■ 関連記事

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

IE6.0がIPv6に対応しなくなったので *1踊るカメ[http://www.kame.net/] を見られなくなって久しかった。
考えてみると、proxyがIPv6で取りに行けば良いわけで、ちょいちょいと設定してやって、踊るカメ復活。
ちなみに、このページのロゴもIPv6だと動くようになっていたりします。
*1: 非公式なパッチはあるようだけれども。

■ 関連記事

■4SCSI-IFボードの入れ替え[freebsd]<< 前の記事 このエントリーをはてなブックマークに追加

batten(という名前のファイルサーバ)のSCSIカードに、Tekram DC-390という非常に古いものを使っていたのだけど、AHA-2940UWが余っていたのを思い出して載せかえた。
特に性能差は感じないけれども、寝かせておくのももったいない。

■ 関連記事

詳細はこの日の詳細から

2005年03月18日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1第三者中継のテスト[おしごと]次の記事 >> このエントリーをはてなブックマークに追加

サーバのバージョンアップ時に、Perlのライブラリを入れ替えたために動かなくなっていたようで、問い合わせを頂いた。若干修正して復旧。
ただ、このテスト自体もはや役目を終えた感があるので、事情説明と自分でどうやって確認したらよいかというコンテンツを作って、サービス終了にしたいと思う。
最近は、デフォルトで第三者中継は許さないように設定するものだし、仮に中継をされるとすると、このテストでやっているような単純な手法ではないから、このテストで安心する弊害の方が大きいかも知れない。
とはいえ、ログを見ると、ぼちぼちは第三者中継を許す設定で立ち上げていて、直してみて直ったことを確認している様子が最近でもあるから、非常に古い書籍などに附属しているCD-Romや設定例で導入しているケースがあるのかも知れない。

■ 関連記事

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

feed mater[http://feedmeter.net/] と、 track feed[http://trackfeed.com/] を導入してみた。
hnsにはログ解析機能があるのだけれども、古い日記に張られたリンクが表示されるのは非常に面白い。

■ 関連記事

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

■ 関連記事

詳細はこの日の詳細から

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

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

■ 関連記事

詳細はこの日の詳細から

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

■1 地震[http://www.mainichi-msn.co.jp/shakai/jiken/news/20050320k0000e040029000c.html]次の記事 >> このエントリーをはてなブックマークに追加

で驚いて起床。棚の上に不安定に置いてあるものが転がり落ちた程度。
サーバ置き場であるところの諫早は震度4程度だったらしい。一通りログをチェックしたけれども、ログに現われるような症状は無し。電源も通信線のリンクも切れなかった様だ。

■ 関連記事

■2 Nifty Corners: rounded corners without images[http://pro.html.it/esempio/nifty/][hns][Webデザイン]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

otsuneさんとこ[http://www.otsune.com/diary/2005/03/19.html#200503191] とかから。うーん。すごいバッドノウハウだ。
一般的なバッドノウハウは、最初に作った人は、それが「バッドな」ノウハウであるということをきちんと認識している。自己署名証明書だってそうだ。開発して最初にやった人のところでは、分かってやってるんだから問題も起きない。
ところが、分かっていない人が結果だけを真似すると困ったことが発生し出す。自己署名証明書のあやうさを理解していなくても、手順だけを追えば自己署名したオレオレ証明書ができあがる。そして、一般市民に対して、オレオレルート証明書をインストールせよということを言い出す。
どうも、この「結果だけ真似て問題を起こす」という現象が、コンピューターの分野では他の分野に比べて、非常におきやすいような気がする。
元の話題の角を丸くするってのも、バッドノウハウだって分かっている人がやっている分には良いのだろうけど、その内、テクニックだけが流布すると、CSSを使ったマークアップ全体がメタメタになってしまうに違いない。
もう少し頑張って、round-corner.css, round-corner.js を読み込んでおいて、
<div class="round-corner">
この周りの枠は丸くなります
</div>
とか書いたら、見えないところで巧妙に処理して、見えないところでよろしくやってくれるというのは作れないだろうか。

■ 関連記事

■3 続・寿司詐欺[?200503b&to=200503172S1#200503172S1]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

お寿司詐欺登場![http://yutunapenguin.ameblo.jp/entry-b46a66540b4f0a069ed14cadd93eaa75.html] の記事が盛り上がっている様です。
スシスシ詐欺[http://dic.yahoo.co.jp/tribute/2005/03/14/1.html] とかいう名前が付いているようですが、「泣き売(ナキバイ)」という由緒正しい呼び名があります。
古典的なやり方では、道ばたなんかで売り子が悲壮感を漂わせて万年筆を売っている、悲壮感で注目を集めることはできますが、これで売り込むのは難しいですから、サクラ登場。寅さんみたいな口上がうまい人が、サクラとして間接的に売り込みをやるわけです。
「おい、何をメソメソして売ってるんだ、そんなんじゃ売れるもんも売れねぇだろう」と大声で話しかけることによって、周囲の関心を集める。同じように不思議に思っていた人が聞き耳を立てる。
「なんだ、工場クビになっちゃったか。そんで退職金代わりに万年筆。これを売らないと生活も立ちゆかない。この不況だもんな。」等と、メソメソしてる役の人は大声で話せないことを、周りの人に聞こえるように解説。
「よし、分かったそういう事情だったら、かわいそうだと思って買ってやるから、モノをきちんと見せてみろ。オレだってこう見えても、万年筆には詳しいんだ。そうやってウソついていい加減な商品売ってるんだったら許さないからな。」とか公平性をアピールしつつ、「なんだ、こんなに良い品物じゃないか。これをこの値段で売るってのは、相当困ってるんだな。」「ねぇ、みなさんも買ってやって下さいよ。」というのがクライマックスだ。
この商法。客の「かわいそうだから何とかしてあげたい」という善意と、「良いモノを安く手に入れたい」という欲の両方に訴求してくるという極めて巧妙な方法だ。
この手でスパコンを売り込む手法も 提案[http://www.t3.rim.or.jp/~s-muraka/bkantei02/kantei19.html] されている様だ。

■ 関連記事

■4 「個人のHP、読み逃げは不可なのでしょうか」[http://www.yomiuri.co.jp/komachi/reader/200501/2005012000034.htm][無断リンク]<< 前の記事 このエントリーをはてなブックマークに追加

「リンクを張る時は相手の許可を得ること」と教育するのは「間違っている」と主張してきた。「許可を得た方が良い」も間違いだ。
教育するならば、 リンクは出典の明記[http://www.nantoka.com/~kei/diary/?200502a&to=200502041#T200502041] だと言うことと、正当な引用とパクリの違いを説明すべきだ。
世の中には、もちろん無断で、正当な引用を行っている出版物やサイトが数多く存在している。「リンクを張る時には相手の許可を得ること」と指導された子どもが、この現実に直面してどの様に考えるだろうか。
正当な引用という概念を知らなければ、「みんなパクッっているじゃないか」と考えてしまうし、自分がページを作った時に、勝手にリンクを張る他人の方を間違っていると判断するようになる。
もっと差し迫ったことを言えば、「このページは友達専用」とかいうページに平気でプライバシーを書いてしまう子が出てくるかも知れない。
「インターネットとは」の説明では、「インターネットでは公開した時点で、誰でも自由に読むし、どこからも参照される」という説明をしたのだから、この原理原則を変える間違ったルールを教える必要はない。
子どもの頃から教育の現場で間違ったこと教えて、再生産されていくと、タイトルの様な人が多数を占めてしまうかも知れない。ウェブの世界ではなくなる。
こういう指導がなされる背景には、 自由なリンクを認めなかったり[?200502a&to=200502033#200502033]リンク設定届出書の提出を要求[?200502a&to=200502042#200502042] するお役所の文化が横たわっている気がする。
お役所のお墨付きを得て、 無断リンク禁止教[http://d.hatena.ne.jp/HiromitsuTakagi/20040426#p2] が布教されていく。

素通り禁止教[http://dp27007957.lolipop.jp/htdocs/mt/200501221009.php]:

関連して色々調べたら、素通り禁止教という宗派が形成されている様だ。
興味深いトラックバックを見つけた。
ここは僕んちだい!来るなら挨拶してけぇ!ってなのも居るわけなんですね。まさに、お子様のサイトがそういうことを言い出していたみたいで、ちょっと微笑ましけど、間違いは間違いだよな。
確かに、「お子様」を中心にこういう主張が増えている気がする。「教育」の成果が着実に上がっている証拠では無かろうか。

■ 関連記事

詳細はこの日の詳細から

以上、10 日分です。

指定日の日記を表示

前月 2005年03月 翌月
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 31

最近の日記

2017年02月21日

BIGの投票内容(発番)につきまして(2017.02.20)

2016年06月29日

「SEI-Net」不正侵入事件にみる佐賀県教育委員会の杜撰

2015年11月26日

武雄市図書館から“地方自治”を考える!

2015年11月21日

シリーズ武雄市TSUTAYA図書館(34) - 「第3のツタヤ図書館にデキレース疑惑 内部資料を独占入手!」落ち穂拾い

2015年10月30日

シリーズ武雄市TSUTAYA図書館(33) - 海老名市ツタヤ館運営の行方

2015年10月26日

シリーズ武雄市TSUTAYA図書館(32) - 10月26日付 文化通信「TRC、CCCとの関係解消へ」

2015年10月25日

シリーズ武雄市TSUTAYA図書館(31) - 続・検証「9つの市民価値」

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

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