2006年12月
2006年12月31日(日曜日)
掲示板/コメント機能修正
hatomaru.dll を修正。
- 画像投稿機能を削除
- 投稿確認画面を追加
といったところ。細かいところはまだ調整中ですが。
例によってバグっているかもしれませんが、バグっていたらごめんなさい。教えてください。
- 「掲示板/コメント機能修正」にコメントを書く
関連する話題: えび日記 / hatomaru.dll
2006年12月30日(土曜日)
マクドナルド最高売上
「マクドナルド、23日の売上が過去最高に (jp.ibtimes.com)」だそうで。
日本マクドナルドは２７日、１２月２３日に１日の売上高２１億５３００万円を記録し、過去３５年の歴史の中で売り上げがもっとも大きな一日となったと発表した。
(～中略～)
また、年末商戦で各店舗が賑わう中、「ハッピーセット」と期間限定商品である「ピタマック 冬野菜チキン」の販売が好調に推移し、２３日が祭日ということもあって家族連れの来客が増えたことも、要因としてあげている。
その「ハッピーセット」の内容については言及されていないのですが、22日から「「ハッピーセット ポケットモンスター」 はじまるよ! (www.pokemon.co.jp)……ということになっているのですね。そしてその日は、
さらに、12月23日(土）限定で「ポケットモンスター ダイヤモンド・パール」に登場するポケモンのキャラクターが集合した「シンオウ地方ポケモン大集合ポスター」がもらえるよ！
というイベントもあったようで。ポケモン強し、ということなのではないでしょうか。
関連する話題: ポケモン
2006年12月29日(金曜日)
マンガ買った
- ひだまりスケッチ 2 (www.amazon.co.jp)
- 最後の制服 3 (www.amazon.co.jp)
- 美味しんぼ 97 (www.amazon.co.jp)
Amazon を見ていたら、「ひだまりスケッチ (2) 限定版 (www.amazon.co.jp)
ポケモン&ゲームセンターCX
年末に向けていろいろ購入。
- ポケットモンスター リーフグリーン (www.amazon.co.jp)
- ゲームセンターCX DVD-BOX 3 (www.amazon.co.jp)
「ポケットモンスター リーフグリーン (www.amazon.co.jp)
同じ理由でエメラルド (www.amazon.co.jp)
……と思っていたら、その田尻智がゲームセンターCX (www.amazon.co.jp)
ところで、これらは例によってビックカメラ新宿西口店で買ったのですが、売り場に行ったら PS3 (www.amazon.co.jp)
ちなみに Wii (www.amazon.co.jp)
2006年12月26日(火曜日)
脆弱性の黙殺は防がれているのか
「議論すべき時が来た組み込み機器のセキュリティ (www.itmedia.co.jp)」という記事が。ごもっともな内容ですが、
間にIPAやJPCERT/CCという調整役を加えることで、ベンダーが情報を黙殺してユーザーを危険な状態に置いたり、あるいは根拠のない非脆弱性情報を流布して不安に陥れるといった事態を防ぐことができる。
黙殺については、あんまり防げていないような気もしますが……。未修正であっても一定期間が過ぎたら公表する、というようなアグレッシブな動きをしているわけではないので、未修正のままユーザーに知らされていないものもたくさんあるのではないでしょうか。
ちなみに最近気になっているのは、せっかく修正・公表されているのに、その脆弱性が放置されてしまっているケースが多いこと。特に気になるのが Movable Type で、2006年9月26日に公表されている脆弱性 (www.sixapart.jp)が放置されているブログがかなりたくさんあります。
これについては情報の公表の仕方にも問題があるような気がしており (というより、Six Apart の Web サイトのユーザビリティに大きな問題があるような……)、公表の仕方についても議論される必要があるのではないかなぁと思います。
※既知の脆弱性の放置って、ウェブアプリケーションの脆弱性として処理されるんでしょうか……。試しに届け出てみようかな。
DNS Pinning
セキュリティホールmemo (www.st.ryukoku.ac.jp)で紹介されていました、DNS Pinning (www.st.ryukoku.ac.jp)というお話、非常に興味深いですね。
たとえ IPアドレスが違っても、ドメインが同じならブラウザは同一ドメインとみなしてくれるというわけで……。なんか、いろいろな応用の仕方がありそうな気がします。
2006年12月25日(月曜日)
IPAテラカワイソス
もういちど「ソニー病」４――屁のつっぱり (facta.co.jp)。
さて、「ケータイWatch」のサイトでも弊誌報道に対するソニーの否定談話が載った。こちらは「FACTA」の名すら出していないし、弊誌に電話さえしない一方的なものだが、独立行政法人「情報処理推進機構」（IPA）の談話を載せている。
フェリカの暗号が破られたという情報が持ち込まれたとする弊誌報道に「持ち込まれたのは事実。ただ、IPAはソフトの脆弱性は受け付けているが、ハードについては対応する権限、および検証能力がない」などとわけのわからないことを言っている。「半分事実で半分事実無根」とはあきれて口がきけない。半分無責任、とでも言ったほうがいい。
わけがわからないですか。そうですか。orz
「情報セキュリティ早期警戒パートナーシップ」は物理デバイスの耐タンパ性の話なんてのは全く想定していませんし、そんなのが vuln-info に送られてきても不受理になるだけでしょう。
……しかしふと、この届出制度がまだ無かった頃に、ウェブアプリケーションの脆弱性を JPCERT/CC に持ち込んでいた人がいたことを思い出したりして。
関連する話題: IPA / 情報セキュリティ早期警戒パートナーシップ
2006年12月22日(金曜日)
JSデータのクロスドメイン参照
「Web2.0時代のAjax Binary Hacks (labs.cybozu.co.jp)」。興味深いお話ですね。
スライドに書かれていますが、クロスドメインでデータをやりとりすること自体は難しいことではありません。script要素の src属性には外部のドメインを指定することができるので、任意のデータを含む js ファイルを動的に生成すればあっさり通信できます。そこに着目したのが JSONP で、外部 .js として実行できる形式にすることによって script要素で参照できるようになり、ドメインを超えられるようになったというわけです。
※ふつう、JSON だと XMLHttpRequest を使うのでクロスドメイン参照できません。
※ちなみに、Opera では JSONP による非同期通信がうまくできなかったりするという問題があったりもするようです。
ときどき「JavaScriptはクロスドメインで参照できない」と思っている人がいるようなのですが、それはおそらく XMLHttpRequest の制限と混同しているのだと思います。要注意なのは、JS ファイルは悪意あるサイトからでも普通に読めてしまうということです。つまり、機微な情報を含むような JS ファイルを動的に生成するのはとても危険だということです。
大昔、某所のチャットのサービスは Java Applet で動いていたのですが、わざわざユーザのセッション情報などを含む JS ファイルを動的生成して、その JS から applet要素や param要素を生成していました。そういう作りをしていると、ログイン状態で罠サイトを踏んだときに、セッション情報を含むデータを読まれてしまうことがあり得ます。このような作りはとても危険です。
2006年12月21日(木曜日)
GBA売り場が縮小?
逆転裁判3 (www.amazon.co.jp)
まず新宿西口のビックカメラに寄ってみたのですが、GBA用ソフトがすくない!! 実は Wii (www.amazon.co.jp)
ということで次に渋谷のビックカメラに寄ってみたのですが、こちらはそもそもゲーム売り場自体が小さいため、GBA用ソフトの売り場もさらに小さくなっています。というわけで、あまり期待していなかったのですが……何故か逆転裁判3 は 3本も置いてあって、見事入手。
※ちなみに、逆転裁判がなかったら「ポケットモンスター ファイアレッド (www.amazon.co.jp)
2006年12月20日(水曜日)
RFC2616の同時接続数の規定
「HTTPの同時接続数はどうあるべきか? (slashdot.jp)」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。
8.1.4 Practical Considerations
(～中略～)
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
こんな感じ。確かに、1人のユーザにつき 2本を超えるコネクションを維持すべきでない (SHOULD NOT) と書いてありますね。
ちなみに、個人的にはこの手の同時接続でサーバが死んだという経験はありません。たまに分割ダウンロードを試みていると思われるアクセスはありますが、長時間持続するわけではないので、そんなに大変なことにはならないようです。むしろ検索エンジンのクローラーが手強くて、BaiduSpider やら dloader やらには泣かされましたが……。
※昔は hatomaru.dll のアルゴリズムがしょぼかったので、ホントに dloader が来たというだけでサーバが DoS 状態になっていました。最近は大丈夫だと思いますが……。ちなみに、Googlebot はアクセス間隔を開けてくれるので、だいたい安心です。
というわけで、個人的にはエンドユーザーが同時接続数を増やすのは特に脅威とは感じません。もっとも、これはあくまで私のサーバのケースなので、画像満載なサイトの管理者にはまた違う意見があるかもしれませんが。
関連する話題: Web / HTTP / dloader / BaiduSpider / RFC
2006年12月18日(月曜日)
届出フォーム
そういえばこんなのが出ていますね……「「脆弱性情報流通・統計システム開発」に係る公募について (www.ipa.go.jp)」。
今回実施するシステム開発により、脆弱性関連情報のウェブ届出フォームを改善し、さらなる届出の増加に備え業務システムの強化を行うことで情報の多角的分析を可能とし、統計データを啓発に役立てることを目的としています。
今の届出フォームは正直言って使えないので、改善されるのでしたら歓迎ですね。フォームを使わなくてもメールで届け出れば良いですし、実際そうしているのですが、メールを PGP で暗号化するのはけっこう面倒です。日常使っているメーラーが Outlook だったりすると特に。なので、フォームが使いやすく、かつ安全なものになってくれれば、そちらを使うようになる可能性は十分にあります。
せっかくなので現状の問題点をいくつか挙げておくと、
- スクリプト無効だと使えない
- フレームが使われている
- 「入力時に半角の # は使用できません。」という意味不明な制限
- 全くアクセシブルでない HTML (そもそも invalid。文法チェックくらいしましょうよ……)
……といったところです。
しかしおそらく、単にこれらを改善するというアプローチにはほとんど意味がないでしょう。このフォームを頻繁に使うようなヘビーユーザーは、ある程度以上のスキルを持っているはずです。フレームの中身の URL を直接叩くなんてのは当然やりますし、フォームの HTML を改善しようと思ったら、自分で書き直してローカルに置いておいても良いわけです。では、実際にそういうことをして使うのかというと、使う気にはならないわけで……。非常に難しい案件だと思いますが、受注した方は頑張ってください。
※まあ、この案件自体は IPA内部のシステムを作る方が主眼のような気もしますが。
関連する話題: IPA / セキュリティ / 情報セキュリティ早期警戒パートナーシップ / フレーム
2006年12月17日(日曜日)
マンガ買った
いろいろ購入。
- よつばと! 6 (www.amazon.co.jp)
- DEATH NOTE 13 (HOW TO READ) (www.amazon.co.jp)
- おとぎ銃士 赤ずきん 1 (www.amazon.co.jp)
ちなみに DEATH NOTE は 12巻で完結していて、この 13 というのは解説本とか設定資料集のようなもの。
2006年12月16日(土曜日)
H18年度ウェブアプリケーション開発者向けセキュリティ実装講座
13日に「H18年度ウェブアプリケーション開発者向けセキュリティ実装講座 (www.ipa.go.jp)」を見てきたので、私なりに思ったことを少し。
【講演1】 脆弱性の届出情報の深刻度評価について
CVSS のお話。「IPA が受付けた脆弱性をCVSSを用いて分析した結果を紹介します」ということで、具体的にこんな事例がこうなった、という話を期待していたのですが……。残念ながら統計データだけで、具体的な事例は出ませんでした。
もっとも、それは私の期待が大きすぎただけで、話としては普通に面白かったと思います。
【講演2】 安全なWebアプリケーションの作り方（番外編）
極楽せきゅあ日記 (d.hatena.ne.jp)などで有名な園田さんの講演。中心はフレームワークのお話で、あとは書籍の脆弱性のお話など。
書籍の話ですが、個人が批判する分には問題ないと思うものの、何をもって誤りとするのかが難しいですね。「のけぞる本!」なんてコンテンツがありますが、これは HTML の仕様に照らして間違いだと言っているので、間違いだと断じるだけの論拠があります。しかし、脆弱なコードを脆弱と判断するのは容易ではないでしょう。特にコードの断片だけ出されている場合、「このコードは入力時のサニタイズを前提としている」などと言われる可能性があります。
「鉄則の話で笑い取れなかった」……とおっしゃっていますが、私と隣にいた人は笑っていたので、一部には受けていたと思います。単純に「鉄則」を知っていたかどうかが分かれ目になっていて、知らない人が多かったのではないかと思いますが……。
※そういえば今年の鉄則 (internetweek.smartseminar.jp)の資料って公開されているのでしょうか?
【講演3】 安全なウェブアプリケーション開発に向けた活用事例
HIRT のお話。HIRT の紹介とか歴史とか苦労話とか。話題がやや拡散していたためか、あんまり印象に残りませんでした (すみません)。
【講演4】 失敗事例から学ぶウェブアプリケーション開発のヒント
脆弱なアンチパターンの紹介。入力時に置換するのは駄目で出力時に処理しなければならない……という話なのですが、駄目な理由がきちんと説明できていない印象を受けました。
たとえば、入力時に全てのパラメータをエスケープする処理、これが駄目な理由が説明できていません。開発が小規模であり、DB を使わず、入力値を HTML にしか出力しない場合には、入力時に全てエスケープしてしまう方法でもあまり問題なかろうかと思いますが……。実際、フリーで配布されている掲示板のスクリプトでは、ReadParse() 相当の処理の中で < などをエスケープしてしまうということが一般的に行われており、これだけで XSS を回避できています。
※入力時にエスケープする方法の問題としては、User-Agent などの処理が漏れること、大規模開発だと多重エスケープ問題が発生したりすること、HTML 以外のもの (たとえば電子メール) に出力しようとすると別のエスケープが必要になるので漏れる危険性があること、などがあります。
危険文字の削除処理の説明についても詰めが甘いと思いました。出ていた例はこんなのですが、
$foo =~ s/script//g;
これが駄目なのは当然でしょう。そこまでは良いのですが、以下のようにすればどうでしょうか。
1 while $foo =~ s/script//g;
この処理なら、指摘されていた問題は起きません。実際、昔ニフティにあった「パレット」という掲示板では後者のような処理をしていまして、この処理自体には問題ありませんでした。
※……とは言え、その「パレット」にも貫通方法がたくさんあったわけで、危険文字の削除という発想が危険なことにはかわりありません。
あと、expression 話では数値文字参照よりも CSS のエスケープの話が必要なのではないかとか、全体として詰めの甘さが目立ちました。言おうとしている内容が間違っているとは思わないのですが、もうちょっと精度の高いお話にできるのではないかと思います。
【講演5】 安全なウェブアプリケーション発注のあり方
経済産業省方面で検討中の、ウェブアプリケーションセキュリティガイドラインのお話。
話の内容は非常に重要なのですが、「開発者向け実装講座」と題するセミナーの内容としてふさわしいかどうかは、やや疑問です。これは実装よりも上流の工程で考慮しなければならない話で、設計はもちろん、サービス企画にまで影響してくる話です。セキュリティ屋や実装屋だけではなくて、いわゆる Web ディレクターであるとか、そういった層に聞いてもらいたい話だと思いました。
最後に、全体通しての感想。
このセミナーに限らず、最近ではウェブの脆弱性に対する「取り組み」の考え方が変わってきているように思います。昔は「まずはテキトーにつくり、脆弱性があったら直す」という状態だったのですが、それでは駄目だというのが共通認識になってきており、「最初から安全なものをつくる」、あるいは「自然に安全なものができる」という方向を目指すようになってきています。その方法のひとつがフレームワークであり、あるいは設計から縛るようなガイドラインであったりするわけです。
個人的には「サニタイズ言うな」という話もその流れの中にあるものだと理解しています。狭義の「サニタイズ」は「テキトーにつくって事後にセキュリティ対策のための処理を追加する」という発想につながる概念で、そのような考え方を助長したくないから「サニタイズ言うな」なのでしょう。
だいたい、XSS なんてのは「何が起きても常に valid な HTML を出力する」という誇りがありさえすれば、それだけで 9割方回避できるのです。ユーザが入力した < を文字参照に変換する処理は、誇りを守るための処理であって、セキュリティを意識したものではないのです。
※ちなみに残りの1割は javascript: スキームとか UTF-7 とか。
逆転裁判2クリア
むらまささん (www.fprog.org)にお借りしていた「逆転裁判2 (www.amazon.co.jp)
……「逆転裁判3 (www.amazon.co.jp)
2006年12月15日(金曜日)
Wiiのストラップ/DSのACアダプタ回収
- 「Ｗｉｉリモコン」のストラップについてのお願い (www.nintendo.co.jp)
- 「ニンテンドーＤＳ」および「ニンテンドーＤＳ Ｌｉｔｅ」専用ACアダプタの一部不良発生についてのお詫びとお願い (www.nintendo.co.jp)
PS2のときと違って、任天堂から先に良品を送ってもらえるみたいですね。ちなみに、うちの DS 2台は交換対象ではありませんでした。
Dreamweaverプロフェッショナル・スタイル
私もちょこっと書いている「Dreamweaverプロフェッショナル・スタイル」ですが、書店にも並んで手に取れるようになったようですので、コマーシャリズム全開で宣伝しておきます。
- MYCOM BOOKS : Dreamweaver プロフェッショナル・スタイル (book.mycom.co.jp)
- 楽天ブックス : Dreamweaverプロフェッショナル・スタイル (hb.afl.rakuten.co.jp)
- Amazon : Dreamweaverプロフェッショナル・スタイル (www.amazon.co.jp)
サポートページ (book.mycom.co.jp)もできております。既に訂正が出ていますが、追加報告しているのでもうちょっと増えると思います (すみません)。
関連する話題: Web / 本 / Dreamweaver
2006年12月13日(水曜日)
本出た
私もちょこっと書いた「Dreamweaverプロフェッショナル・スタイル (www.amazon.co.jp)
※2400円と聞いていたのに……と思いましたが、税込みで 2520円なのですね。
関連する話題: Web / 本 / Dreamweaver
続きはWebで
「H18年度ウェブアプリケーション開発者向けセキュリティ実装講座 (www.ipa.go.jp)」というのがあったわけですが、あとでいろいろ書きます。
※ところで「続きはWebで」を実際にやってみると、ある意味雨やどりの話 (takagi-hiromitsu.jp)と同じような状態になっているような気がするのですが、これは教訓ということなのでしょうか……。ちなみに、17人くらいいらっしゃったようです。
2006年12月9日(土曜日)
逆転裁判クリア
むらまささん (www.fprog.org)にお借りしていた「逆転裁判 蘇る逆転 (www.amazon.co.jp)
非常に面白かったのですが、最後の「蘇る逆転」のシナリオには個人的に異議ありな点が残ってしまっており、そこがやや微妙。
- パスワードが脆弱すぎ (これはまあ良い)
- 2年前の犯人の動機が理解不能。身内を殺してまですることとは思えないし。
- 2年前の犯人の行動が理解不能。既に騒ぎになっているのだからいつ人が来るか分からない状況だし、倒れている3人が目覚めるかもしれない。特に、青葉が目覚めて逃げたりしたら最悪なので、普通はまず青葉を拘束すると思いますが、どうですかね。殺人を犯したり工作をしていたりする場合じゃなかろうに。
- 2年前の犯人の行動に異議あり。現場は真っ暗だったのではないかと思いますが、茜の指紋がついていることが分かったりするのですかね。
いま逆転裁判2 (www.amazon.co.jp)
事実上名指し
「企業のWebアプリケーションには100％脆弱性がある」---セキュアスカイ社長 乗口雅充氏 (itpro.nikkeibp.co.jp)。
うーん……。
乗口氏がセキュアスカイ・テクノロジーを設立した2006年3月以降，ユーザー企業のWebアプリケーションを検査してきたが，実際に顧客のシステムを検査してみると，必ず脆弱性が見つかるという。「多くの企業にとっては脆弱性があるのか無いのかということが問題なのではなく，脆弱性が発覚しないことが目的になっている」
余計なお世話かもしれませんが、この発言、大丈夫なのでしょうか。
セキュアスカイ・テクノロジーの主要取引先 (www.securesky-tech.com)のページを見ると、そこに掲載されている社名は 3つだけしかありません。この状態で、「100%」という数字を出しつつ先に引用したような発言がなされると、それは 3社を名指しして言っているも同然になってしまいます。
そして私はポケモン (www.amazon.co.jp)
要するに、セキュアスカイ・テクノロジーの社長の発言からは「株式会社ポケモンのサイトには脆弱性があった」と断定できるのですが、サイトの利用者である私はそのようなお知らせを全く受けていないので、これはなかなか複雑な気持ちになります。
※まあ、私の経験からしてもウェブアプリの脆弱性が公表されることは極めて希で、多くの企業が脆弱性を公表しないという事は事実でしょう。なので言っていることは間違っていないと思いますが。
※この記事には他にも思うところがありますが、それはまたの機会に……。
2006年12月8日(金曜日)
マシン死亡@CSS Nite LP, Disk 2
「CSS Nite LP, Vol.2、終了しました。 (cssnite.jp)」……お疲れ様でした。
無事終了……と言いたいところですが、セッションの一つでは、講演者が話し始めようとしたところでプレゼン資料上映用の PCが死亡、しかも再起不能になるという、かなり厳しいトラブルに見舞われました。
……いや、9月に講演したときからバッテリの減りが異様に早いとは思っていたのですが、当日は「AC アダプタを接続しているのにバッテリが減る」という無茶苦茶な状態でした。それでも 1時間半は保ったのですが (一つ前のセッションで同僚が同じマシンを使っていた)、私の番になって力尽きた模様です。
幸い、司会の益子さんがマシンを貸してくださったので何とかなりましたが (ありがとうございます)、このマシンはもう駄目っぽいですね……。
2006年12月6日(水曜日)
宜保愛子は凄い!
「ギボギボ90分!―と学会レポート (www.amazon.co.jp)
また、ビリーバーが信じてしまう背景に「こんなおばちゃんが……」という差別的な意識があるのではないか、という指摘も鋭いと思います。
※どうでも良いですが、Amazon のレビューが 1 と 5 の両極端に割れているのが面白いですね。
届出FAQ
「脆弱性関連情報の届出関連 FAQ (www.ipa.go.jp)」というものができていますね。心当たりが多すぎて面白いです。
Q1-12：IPAより届出た脆弱性が修正されたと連絡が来ましたが、確認してみたら、修正されていませんでした。このような場合はどうすればいいでしょうか？
IPAでは脆弱性の修正をご連絡する際に、発見者が脆弱性の修正を確認する期間として10営業日の期間を設けています。脆弱性が修正されていないことが判明した場合、この期間の内に、修正されていないと判断した理由を具体的にご連絡ください。発見者より脆弱性が修正されていない旨の連絡があった場合、届出の取扱いを続けさせていただきます。
……これ、私が質問したのは「フリーフォーマットで返信して良いのか、また様式にそって書いた方が良いのか」という事で、そのときは「できれば様式で」というご回答でした。これを見ると「理由を具体的に」ということなので、フリーフォーマットで良くなったみたいですね。
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ
花子パッチは Windows Server 2003 ユーザには厳しい
「JVN#47272891 花子におけるバッファオーバーフローの脆弱性 (jvn.jp)」……ということで、パッチがリリースされております……「「一太郎2005/2004、花子2006/2005/2004、三四郎2005 セキュリティ更新モジュール」、「一太郎ビューア」、「花子ビューア」、「一太郎Lite2 セキュリティ更新モジュール」の公開 (www.justsystem.co.jp)」。
……で、サーバにパッチを当てるべく「一太郎、花子、三四郎用のダウンロードはこちら」を押すと、見事に何も起きないわけですね。もうね。
※Windows Server 2003 の IE はデフォルトでスクリプト無効なのです。
HTML のソースを読んで何とかダウンロードしましたが、Windows Server 2003 のユーザはパッチを適用できなくても問題ないのですかね。まあ、Windows Server 2003 にインストールしている方がイレギュラーだと言われれば、それはそうかもしれないと思いますが。
2006年12月3日(日曜日)
mixiコミュニティから訴訟の動き?
mixi にこんなトピックスがあったのでメモ。
※以下のリンクは mixi 内のもので、会員専用です。あしからず。
- [mixi] 嫌煙家 | みんなで告訴したい (mixi.jp)
- [mixi] 嫌煙家 | みんなで告訴したい 【訴状編】 (mixi.jp)
民事になると思うので、「告訴」とは言わないような気もしますが、まあそれはともかく、「飲み会等も殆ど行けません」という話が悲しいですね。
ちなみに、健康増進法第25条 (law.e-gov.go.jp)には次のような規定があります。
学校、体育館、病院、劇場、観覧場、集会場、展示場、百貨店、事務所、官公庁施設、飲食店その他の多数の者が利用する施設を管理する者は、これらを利用する者について、受動喫煙（室内又はこれに準ずる環境において、他人のたばこの煙を吸わされることをいう。）を防止するために必要な措置を講ずるように努めなければならない。
飲食店はここに含まれる訳ですから、分煙されていない飲み屋は違法な状態になっているわけですが、罰則がないので華麗にスルーされてしまう訳ですね。厚生労働省の「受動喫煙防止対策について (www.mhlw.go.jp)」などを見ると、
健康増進法第２５条の対象となる施設の管理者は多岐にわたるが、これら管理者を集めて受動喫煙の健康への悪影響や各地の好事例の紹介等を内容とした講習会を開催するなど、本条の趣旨等の周知徹底を図る。
などと述べられていますが、ホントにやっているのかどうかはよく分かりません。
……が、実は真の問題は、たとえ店が分煙であっても、同伴者が喫煙を望んだらどうにもならないということです。そもそも喫煙者と一緒に飲んだり食べたりすること自体が難しいので (物理的には可能ですが長時間続けると体調が悪くなってきたりする)、店が分煙されただけではあまり解決にならなかったりします。どうしたものですかね……。
関連する話題: たばこ
2006年12月2日(土曜日)
Wii出た
Wii が発売されたということで、各所で盛り上がっている模様ですね。
欲しいことは欲しいのですが、最近は PS2 も全く起動していないわけでして。DS なら電車の中でプレイできるのですが、据え置き型ゲーム機で遊んでいる時間はちょっと無いなぁ……ということでスルーしております。現状ではソフトがあんまり無いということもありまして、どうぶつの森 (www.amazon.co.jp)
……さて、問題は誰が Wii を会社に持ってくるのかということであり……。
※え? 持ってこいという圧力なんかじゃありませんよ、決して。
2006年12月1日(金曜日)
幻の時間延長
JIS X 8341-3 の 5.3. には、以下のような規定があります。
c) 入力に時間制限を設けないことが望ましい。制限時間があるときは事前に知らせなければならない。
d) 制限時間があるときは、利用者によって時間制限を延長又は解除できることが望ましい。これができないときは、代替手段を用意しなければならない。
ちなみに元ネタとなっているのは、Section508 Standards 1194.22 Web-based intranet and internet information and applications. (www.section508.gov) の (p) にあるこの条文です。
When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
人によっては素早い入力ができない場合があり、フォームを埋めるのに何十分もかかるかもしれません。セッションタイムアウトの時間が短く設定されていると、なんらかの理由で入力に時間がかかる人は、どう頑張っても入力ができないという事になってしまいます。ですので、タイムアウト時間を設けない、あるいは延長できるようにするという対応が求められるわけです。
これは十分に根拠のある話だと思いますし、JIS X 8341-3 では、例として「ログアウトまでの時間延長」というボタンを設けるような例も記載されていて、かなり分かりやすく説明されています (JIS X 8341-3 はかなり難解ですが、ここは分かりやすい部類だと思います)。
……しかし、ログアウト時間延長ボタンを持っているアプリケーションって見たことないのですよね……。
- 前(古い): 2006年11月のえび日記
- 次(新しい): 2007年1月のえび日記
