2003年7月
2003年7月31日(木曜日)
Windows 2000 Server で DCOM を無効にする
MS03-026 を当てても駄目なことがあるらしいので DCOM を無効に。
DCOM を無効にする方法は小島さんの「DCOM を無効にする (www.st.ryukoku.ac.jp)」に詳しいですが、Windows 2000 Server の場合は「管理ツール」の中に「コンポーネントサービス」がありますので、Windows XP と同じ方法で無効にできます。
……なんか無効にしたら再起動求められました。サーバはあんまり再起動したりしたくないですが、しゃあない、再起動。とりあえず問題ないみたいですね。
- 「Windows 2000 Server で DCOM を無効にする」へのコメント (5件)
関連する話題: セキュリティ
2003年7月30日(水曜日)
2003年7月29日(火曜日)
PDF をダウンロードさせる
更新: 2003年7月30日
PDF ファイルをブラウザ内で開くわずらわしさを回避しつつダウンロードする手順も掲載しておくといいだろう。残念ながら、現状のテクノロジーでは、これは一般ユーザには難しい操作だ。ファイルを表示しないでダウンロードする特殊なリンクが作れるようになるといいのだが。
PDF の Content-Type: が application/octet-stream になるようにしておけば、勝手にダウンロードになったりしないでしょうか。そんなに難しい対処ではないと思いますが。
それとも、例によって IE が Content-Type を無視して自動判別の結果を優先したりするのでしょうか。PDF まで自動判別するのかしら？ 手元に適切な PDF のリソースがないので試せないですが……。
※追記 : yuuさんからテスト用の PDF ドキュメントを頂きました。ありがとうございます。そんなわけで、application/octet-stream な PDF へのリンク。試してみましたが、やっぱり MSIE6 は Content-Type を無視して PDF として表示しようとするみたいですね。とほほほ……。Content-Type 無視はセキュリティ上の問題にもなりますから、本当に何とかしてもらいたいものですが。
※2003-07-30 追記 : Content-disposition: attachment を付けるとダウンロードになるのではないかというご指摘を頂きました (えむけいさん、yuuさんありかとうございます)。そんなわけで、application/octet-stream かつ Content-disposition: attachment な PDF へのリンク。……おお、確かにダウンロードになりますね！ これで Jakob さんも安心。
XSS大王シリーズ終焉か
例のニフティ Web フォーラムのセキュリティホールですが、こんなアナウンスが出ています。
継続して行っております脆弱性対応の一環としてフォーラムについてサブドメイン化を行わせていただくこととなりました。このサブドメイン化を行うことにより、脆弱性対応についての大きな作業は完了となります。
どうしてサブドメイン化がセキュリティ対応なのかについては、ここを読んでいる人には説明不要でしょう。
※でも一応書いておきますと、Cookie の有効ドメイン範囲を修正し、hpcgi1.nifty.com などから読まれないようにするためですね。
これが完了すれば、私が把握している Web フォーラムのセキュリティホールは全て対応されることになります。
……よく見ると URL が https じゃなくて http だったり、高木さんのところ (staff.aist.go.jp)にはちょうど良いタイミングで「Cookie盗聴によるWebアプリケーションハイジャックの危険性とその対策」と題する PDF のドキュメントが出ていたりしますが、まあその辺りは気づかなかったことにしておきましょうか……。
※蛇足ですがこれも一応説明しておくと、要するに、ニフティはパケット盗聴によるセッションハイジャックを考慮していない可能性があるということです。昔から http と https が良く分からない感じで入り乱れていたりしましたし。
なお、Web フォーラムとパレットは別のサービスです。この対処は「@nifty パレットのセキュリティホール まとめ」に書かれているセキュリティホールには影響ありません。
2003年7月28日(月曜日)
間違いのレベル
ただ，わざわざ間違いを教える(単純化するために敢えて現段階では間違いを許容するというものならともかく，今回の朝日のソレでは何も単純になっていない)のはどうかと思う。たとえば学校で教えたことを全員が100%覚えて正しく使うわけではないが，だからといって教師が間違った内容を教えてはいけない。話を単純にするために適用範囲をあいまいにしておくとかいったことはよくあるが，それでも後で何かを補えば正しくなるといったものでなくてはならない。
以上、わたやんさんのvalid HTML 命というわけではない(The Net) より
全くその通りだと思います。議論を見ていると「初心者にやる気を出させることが重要」などという話にまで発展させてしまっている人がいるようですが、今回の話はそんなレベルの高い問題ではありません。著者の教える姿勢や考え方にも問題はあると思いますが、致命的な問題はそこではなくて、例として出している HTML が単純に間違っているということです。単に、
<font color="blue">
<H1><center>ホームページ講座３回のスケジュール
</center></H1></font>
となってしまっている例を、
<center><H1><font color="blue">
ホームページ講座３回のスケジュール
</font></H1></center>
と直せば、これだけでもう 30倍くらいマシになります。2回目の例についても、
<img src="fr.gif" alt=フロントランナー>
となってしまっている部分を、
<img src="fr.gif" alt="フロントランナー">
と、引用符を追加するだけで 50倍くらい良くなります。
この修正によって「初心者」の理解が困難になるとか、とっつきにくくなるとか、そういったことが起きるとはとうてい思えません。教える姿勢とか考え方とか、そういうレベルの話ではないのです。
文書型宣言や title要素については、ステップを追って補って行けば良いと考えられます (実際、title要素は 2回目で補われています)。しかし、不正な要素入れ子構造を手本として示す意味は全く理解できません。後者のようにできない理由は何もないでしょう。
ちなみに、私が望ましいと考える対処は、
- HTML の例文を上述のように訂正する (1回目、2回目共に)
- 1回目の「ほとんど嫌がらせかとも思えますが」という表現は不適切であったとして撤回する
の 2点です。これだけでずいぶん良くなるでしょうし、あえてそれ以上のことを求める必要はないと思っています。
2003年7月27日(日曜日)
確率計算
確率 1/5 で起きる事象が 7回の試行中 4回以上発生する確率は、2605 / 78125 で、約 1/30。
もちろんこれは実験が完全な制御下にあったという仮定に基づきます。
関連する話題: メモ
死の香り
お茶がらを捨てようと思って流しの横のごみ箱を開けたら、何か赤っぽいものが捨ててあるのが目に入りました。
一瞬の後、ものすごい匂いが。
赤い何かは唐辛子系の何かであるらしく、その匂いには明らかに痛覚に訴えてくる成分が含まれていました。ただでさえ高い攻撃力を誇る夏場の生ゴミの匂いに、この成分が加わったらもう最強です。思い浮かんだ言葉は「鬼に金棒」。
※このゴミ、普段から煙草のヤニの臭いの成分が含まれているのがとても凶悪です。灰皿もここで洗っているのでしょうか。
一瞬本気で気が遠くなりました。何とか持ちこたえましたが、激しく咳き込み、吐き気と戦う羽目に。
だから、匂いには弱いのですってば。
関連する話題: 出来事
メタ言語忘却
「小さな蟻と大きな蟻」と言った場合、それは蟻の中でも特に小さいもの、大きいものという意味でしょう。ここでの「小さな」は、「蟻」という集合にフィルタをかけて大きめのものを取り除き、小さいものだけを取り上げる役割を果たしています。
しかし「小さな蟻と大きな象」と言った場合、最初の「小さな」には「蟻」という集合にフィルタをかけるような役割はありません。単に象と比較して蟻というものはことごとく小さいと言っているに過ぎません。
で、この二つの異なる用法にはそれぞれ呼び名があったはずなのですが、それを何というのかがはっきりと思い出せず。「限定用法」あるいは「制限用法」に対して、「非限定用法」あるいは「非制限用法」でしたっけか。英語には「限定用法」と「叙述用法」というのがあったような。いろいろ混乱気味です。
関連する話題: 言葉
続・やってもうた
朝日新聞のあれは続編が出ましたね。「夏休みホームページ作り（中） (www.be.asahi.com)」。
「”」と「”」の間に画像のファイル名を拡張子まで含めて入れてください。また、その画像がいったい何なのか、説明をつけるのがルールです。ちょっと面倒ですが、忘れないようにしましょう。図【５】の７行目の「ａｌｔ＝フロントランナー」の部分です。
「alt=フロントランナー」ではなくて、「alt="フロントランナー"」の typo でしょう……と思いつつ、例のソースを見てみます。前回同様画像になってしまっていますので、読めない人のためにテキストにして引用しておきます。
<html>
<title>画像張りつけ例</title>
<body bgcolor="aqua">
<font color="blue">
<H1><center>ｂｅ各面のメーン記事</center></H1></font>
ｂ２<br>
<img src="fr.gif" alt=フロントランナー><br><br>
ｂ３<br>
<img src="repo.gif" alt=リポート><br><br>
ｂ４<br>
<img src="ichi.gif" alt=一流を育てる><br><br>
ｂ５<br>
<img src="okane.gif" alt=お金の悩み><br><br>
ｂ６<br>
<img src="manu.gif" alt=マニュアル不要><br><br>
ｂ７<br>
<img src="between.gif" alt=ビットイン><br>
</body>
</html>
alt属性の値、ことごとく括られていません。解説文中の表記は typo ではなかった模様。
値に日本語の文字を含むような場合、属性値の引用符は省略できません。実際にはブラウザの強力なエラー補正能力で何とかなる場合もありますが、値に空白が入ってきたりすると本気で誤動作しますので危険です。逆に、文中で「括れ」と指導しているファイル名部分に関しては、上記のような値であれば引用符省略可能です。
※ただし、値に / などを含むと引用符が必要です。また、XHTML の場合は引用符の省略は一切できません。いずれにしても全部引用符をつけておけば問題ありません。
※属性値の引用符がどういうときに省略できるのかについては明確なルールがあります。詳しくは「SGML の短縮タグ機構」を参照してください。
そもそも、alt属性の値とは何なのかという説明が、「また、その画像がいったい何なのか、説明をつけるのがルールです。」で終わっているのが壮絶です。これで行くと alt="" などという指定はあり得ないでしょう。紙面の都合はあるのでしょうけれど、「画像が表示できない環境で、画像の代わりに表示するテキストです」くらいの説明は入りそうに思うのですが。
※まさか、著者が本気で alt属性の意義を理解していないなんてことはないですよね、いくら何でも。そう信じたいですが……。
あとソースを見ると、title要素が出現していて一歩前進。
※head要素の開始タグ終了タグがないのも気になりますが、XHTML でない HTML では head要素の開始タグ終了タグはともに省略可能です。パーサは適切な場所にタグを補って解釈することができます。しかし title要素は開始タグも終了タグも省略不可能ですから、勝手に補うことはできません。前の例は本当に title要素がない状態でした。
しかし、相変わらず font要素の中に H1、H1 の中に center を入れちゃっています。前回のそれは、あるいは一時の気の迷いかとも思いましたが、著者は本気でこういう書き方ができるものと思っているようですね。
今回はさらに、例の下に「覚えよう！タグ一覧」と題した表が出ているのですが、これがまた強烈です。これまた画像なのでテキストにして表にしておきます。
覚えよう！ タグ一覧 <basefont size="n"></basefont> 文字の基準サイズ設定です。nには1から7までの数字が入り、数字が大きいほどサイズも大きくなります。指定しないとn=3になります <big></big> 文字サイズを1段階大きくします <small></small> 文字サイズを1段階小さくします <img src="～"> 表示する画像ファイルを指定します。～にファイル名を入れます <img width="～"> <img height="～"> 画像の横幅(heightにすると縦幅)をピクセル数で指示します。～には数字が入ります。どちらか片方だけ指示すると縦横比をを保ったまま縮小・拡大されます <img alt="～"> その画像が何なのか説明文(～の部分)を付けます
いきなり basefont要素に終了タグが！ これは XHTML なのでしょうか？ だとすると img要素にも終了タグが必要なのですが……。しかも、これを見ても basefont要素の使い方は全く分からないような気がしますけれども。
※まあ、そもそも basefont 要素自体が全く必要がありませんので、使い方が分からなくても問題ないような気もします。
この一覧がどういう基準で選定されているのかも謎です。img要素については、今回のテーマからして分かるのですが、basefont, big, small については何の脈絡もありません。そもそも、basefont や big や small って使いますか？ 論理マークアップを理解していないことを差し引いてもなお、あまり使わない気がするのですが……。
2003年7月26日(土曜日)
2003年7月25日(金曜日)
モンスター行方不明
ポポローグ (www.amazon.co.jp)
ちょっと進むと出てこなくなるモンスター、いっぱいいそうですね。モンスター図鑑完成を目指す場合は、初出のモンスターはもうその場で 15体やっつけるくらいの勢いで行かないといけないかも。
……どうでも良いですけれど、ザッパってちょっと弱いような。防御力が意外に低いですし……。
輝く「テスト」
フロートの中身が選択できないという罠が、燦然と輝く「テスト」の文字で何故か解決。意味がまったく分かりませんけれども。
2003年7月24日(木曜日)
ギルタ
更新: 2003年8月4日
ポポローグ (www.amazon.co.jp)
モンスター図鑑にはお宝の欄があって、最大で 2つのアイテムが載ります。欄が 2つ埋まっていて、さらに異なるアイテムが出るのであれば「欄が足りなかったので出ていない」のだと解釈できますが、イビルフェイスのお宝は「ぎんのうでわ」しか出ていないのですよね……。
※追記: これはおそらくバグです。ポポローグのバグ その2を参照。
逆に、「お宝の欄が 1つしか埋まっていないモンスターは、もう一つレアアイテムを持っている」ということになっているのかしら……？ ともあれ、モンスター図鑑に出ていないお宝があり得るということを学習しました。
latest versions
WCAG1.0 の 11.1 にはこんな項目があります。
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2]
以上、WCAG1.0 11.1 より
この後半の "the latest versions" とは、たとえば HTML3.2 ではなく HTML4.01、という意味だと思っていました。一般的に、より新しい仕様の方がよりアクセス性を考慮しているでしょうから、より新しい仕様の方を使うべきだと。実際、HTML3.2 と HTML4.01 を比較すると、アクセス性に関する配慮は比較にならないほど違います。
しかしそうではなくて、"the latest versions" というのは、「同じ仕様の最新の文書」を指すのではないかという指摘をいただきました。たとえば HTML4.0 は 1997-12-18 に Recommendation となった後、1998-04-24 に改訂されています。このような場合に、改訂された新しい版を使用すべしと言っているのではないかという話です。
※HTML4.0 はそもそも HTML4.01 で上書きされているので例として不適切なのですが、HTML4.01 は Recommendation になってから一度もアップデートされていないので……。
HTML の仕様書では両者いずれも "version" と呼ばれていますので、どちらの解釈も可能です。最新の文書を見るというのは言われるまでもなく当たり前のことではあるのですが、当たり前のことをあえて言っている可能性もあります。
ただ、そうしたときに気になるのは次の項目。
11.2 Avoid deprecated features of W3C technologies. [Priority 2] (Checkpoint 11.2)
以上、WCAG1.0 11.2 より
HTML3.2 では xmp や listing くらいしか deprecated とされていないわけで、HTML3.2 を採用して良いとなると、HTML3.2 でマーク付けをした場合には HTML4 で deprecated とされた要素や属性を使用しても問題ない、という結論になってしまいます。文書型宣言を付け替えただけで、ある要素のアクセス性評価が変わってしまうのは変でしょう。
もっとも、WCAG1.0 では "deprecated" という語を以下のように定義しています。
A deprecated element or attribute is one that has been outdated by newer constructs. Deprecated elements may become obsolete in future versions of HTML. The index of HTML elements and attributes in the Techniques Document indicates which elements and attributes are deprecated in HTML 4.0.
HTML4.0 で deprecated とされているもののリストを提供しているところから、この "deprecated" はあくまで HTML4.0 における deprecated を指す、という解釈は可能でしょう。その場合、HTML3.2 を使用している場合でも、HTML4 において "deprecated" なものを使用しないことが求められることになります。これならば特に問題はないでしょう。
HTML から離れて思考してみると、CSS1 と CSS2、DOM1 と DOM2 などについては、どちらがアクセス性が高いとはあまり言えない気がします。ただ、これらについている数字はそもそもバージョンではなくレベルなので、どちらの解釈をとっても「CSS1 と CSS2 のどちらを使うべきかについてはこの項目は何も言っていない」という結論になります。
XHTML1.0 と XHTML1.1 辺りについて考えると微妙なところですが、そもそも前半に "when they are available and appropriate for a task" という要件があります。前者の場合であっても「適する範囲でもっとも新しいものを」という意味に解釈するしかありませんので、XHTML1.1 が目的に適さない場合には採用しなくて良いことになります。これは HTML4.01 と HTML3.2 についても同様です。
……そんなわけでいろいろ考えてみましたが、やはりどちらの解釈も可能なように思えます。
まあ、いずれにしても HTML3.2 では他のチェックポイントを満たすことができませんから、11.1 によって排除されてもされなくても「WCAG1.0 に従うのであれば HTML3.2 は採用できない」という結論には変わりありません。WCAG 自体も、2.0 の WD ではがらりと変わっていたりしますし、あまりこだわらなくても良いような気はしています。
2003年7月23日(水曜日)
検定で GO!
「インターネット ルール＆マナー検定 (rm.iajapan.org)」。話題のようなので、みぃはぁな私は早速「信頼済みサイト」に登録してチャレンジしてみました。
※「信頼」するのはスクリプトを有効にするためです。ちなみに、フォームの submit ボタンのようなものは実際には submit ボタンではありません。そのため、IE6 でもパスワードのオートコンプリートが利用できないという結構つらい罠があります。
いろいろな意味で難問揃いです。私が特に悩んだのはこれ。
設問 50 インターネットで、半角カナ（JIS X 0201カナ集合）を使ってはならないとされる理由を選びなさい。
1 全角と半角の2つは必要ないから
2 文字が小さくて読みにくいから
3 半角カナは時代遅れだから
4 インターネットの標準には含まれていないから
消去法で考えました。まず、明確に判断できるのは 4 です。半角カナが「インターネットの標準」に含まれているかは客観的に判断できます。
※見た瞬間に「インターネットの標準」とは何なのかという疑問が湧く人もいるでしょうけれど、実は設問 17 に「インターネットで使われる技術の標準を記した文書は」という問題がありました。その選択肢は GNU, RFC, ISO, XML でした。答えは GNU や XML ではあり得ませんし、ISO は組織であって文書ではありませんから、問題作成者は「インターネットの標準」たる基準を RFC に求めているものと思われます。ここではそれを前提として考えています。
さて半角カナですが、これは ISO10646 (Unicode) の基本多言語面に "halfwidth-katakana-letter" として定義されている文字で、UTF-8 (RFC2279) でも UTF-16 (RFC2781) でも問題なく表現することができます。ISO に根拠を求めても、RFC に根拠を求めても、半角カナが「含まれている」ことは明確です。これが「インターネットの標準」に含まれることは間違いないでしょう。よって 4 は消えます。
ただし、話をインターネットメールに限るなら 4 が正解となる可能性はあります。日本語のメールでは、今でも文字符号化方式は ISO-2022-JP (RFC1468) が主流です。ISO-2022-JP では、そもそも半角カナが表現できません。にもかかわらず、それを無理やり独自の符号化で表現しようとするメーラが存在していて、そのため半角カナを使用すると文字化けして読めなくなることがよくありました。しかし、これは特定のメーラの実装に関する問題に過ぎませんし、UTF-7 (RFC2152) で符号化したメールで半角カナを使用するという選択肢もありますから、やはり「インターネットの標準」に半角カナは含まれることになるでしょう。
これで 4 が消えましたので、次に 2 について検討します。文字が小さくて読みにくいかどうかは、ユーザのフォントの設定などに依存する問題です。実際、「MS UI ゴシック」などでは全角のカタカナも半角のカタカナも大差ありません。濁点や半濁点が文字と独立しているのが読みにくい、という話を聞いたことがありますが、選択肢 2 はあくまで文字の大きさだけを問題にしていますから、違うでしょう。
これで 2 が消え、残ったのは 1 と 3 ですが、実はどちらにも論拠があります。ISO 10646 は「一つの文字には一つのコードポイントを割り当てる」ということを前提としています (そのために「似たような文字」がくっついてしまったりしていますが、それはまた別の話)。この原則からすると全角と半角は一つにまとまるべきなのですが、既存の符号化方式との変換の際に支障が出るという理由で、あえて半角カナを定義しています。つまり以下のようなことが言えます。
- 本当は一つであるべき (全角と半角の2つは必要ない)
- 過去に使われていた符号化方式との互換性のために用意されている (半角カナは時代遅れ)
こう考えると 1 と 3 のどちらも正しいのですが、後者についてよく考えてみると、Shift_JIS や EUC-JP などは本当に過去のものなのか、という疑問が湧きます。UTF-8 が使われる場面は増えてきましたが、現在でも Web サイトの多くは Shift_JIS や EUC-JP などで符号化されています。
これで 3 が消え、1 が残りました。自信をもって回答したのですが……。
正解 4
解説
日本語のメッセージをやりとりするためのエンコーディング方法は、 RFC1554に定義されています。インターネットのようなさまざまな環境で互換性が期待できるのは、標準としてRFC1554に定義されている ISO-2022-JP (RFC1468), ISO-2022-JP2 (RFC1554) となります。これには、JIS X 0201カナ集合は含まれていないことから、使わない方が望ましいとされています。
やってもうた。
……いや、いちおうそういう (出題者がショボイという) 可能性も考えないではなかったのですが、「JIS X 0201カナ集合」なんて言葉が使われているので、出題者は JIS 規格や ISO 規格や RFC などの内容には精通しているのかなと思ってしまったりした次第でありまして。
※しつこいようですが明確に宣言しておきますと、HTML の仕様は文字符号化方式を ISO-2022-JP に限定などしておらず、むしろ RFC2854 などは明確に UTF-8 を推奨しています。そして前に述べたとおり、UTF-8 では半角カタカナが表現できます。使うべきかどうかはまた別の話ですが、少なくとも「RFC に含まれていない」というのは完全に誤りといって良いでしょう。
あとついでに、私が自信を持って間違えた問題。
設問 73 Webページから動画や音声など大型のファイルをダウンロードできるようにする場合、表示しておくと親切な情報を選びなさい。
1 ファイル形式を表示しておく
2 ファイル名を表示しておく
3 ファイルが大きいと注意しておく
4 ファイルサイズを表示しておく
ファイルをダウンロードしても、それが自分の環境で利用できないものだったら意味がありません。特に動画や音声にはファイル形式がたくさんありますから、必ずしも再生できるとは限りません。ファイルが大きければそれだけ「ダウンロードしたけど再生できなかった」時のダメージは大きくなるでしょう。サイズも重要ですが、それ以前にまずファイル形式を明示しなければお話になりません。
こう考えて、自信を持って 1 を選択。
正解 4
解説
動画や音声などサイズの大きいデータを配布する（ダウンロードさせる）場合は、前もってそのデータのサイズを表示しておきましょう。（一般版「インターネットを利用する方のためのルール＆マナー集」 - 「6. ホームページ」より）
……ひょっとして考えすぎなのでしょうか、私。
もうひとつ。
設問88 パソコンのシステムカレンダーと時計が実際より３日ほど早くなっていました。こうしたパソコンから送られたメールは、相手方にどのように見えるでしょう？次から正しいと思われるものを選びなさい。
1 そうしたメールは届かない
2 日付が３日後の「未来からのメール」になる
3 日付が３日前の「過去からのメール」になる
4 サーバが日付や時間を直してくれるので影響ない
分かりやすく (?) 言い換えると「メールヘッダの Date: フィールドはどの時計に依存するか」という問題です。これは最初に SMTP を喋ったものが設定しているはずです。
LAN など組まれておらずスタンドアローンで稼働している Windows + Outlook Express というようなクライアントマシンを仮定すると、メールクライアントはそのマシンの設定時刻を元に Date: を生成して SMTP に渡すことになるでしょう。従って Date: の値はクライアントマシンの時計に依存します。
しかし、telnet でメールを読んでいるような人 (犀川先生?) などを仮定すると、その人はログイン先のサーバ内で MUA を起動して使っているわけで、送信時にはそれがそのままサーバ内の MTA にメールを渡すことになります。この場合は telnet 端末側の時刻設定など全く関係なく、サーバの時計が使われるでしょう。そんな極端な例でなくても、グループウェアを使っている場合はグループウェアのサーバが SMTP を喋りますから、クライアントの時計ではなくサーバの時計が使われます (これは実際に Microsoft Exchange Server が導入されている環境で確認しました)。
普通はまず前者を想定するところですが、私の念頭には何故か後者の例しか出てきませんでしたので、迷わず 4 と答えてしまいました。きっと犀川先生のせいだと思いますが、それはともかくとして、用意されていた正解はこんな感じでした。
正解 2
解説
カレンダー設定や時刻設定が狂っているパソコンから出されたメールは、相手方のメールボックスに狂ったタイムスタンプのまま格納されます。メールを整理したり、話の流れを追ううえで、あまり好ましいこととはいえません。パソコンのカレンダー、時刻設定は正確にしておきましょう。
ああそうね、と一瞬思いましたが待ってください。3 (過去からのメール) ではなく 2 (未来からのメール)? 設問には「実際より 3日ほど早くなっていた」とありますが、これはたとえば実際は 7月23日であるところが、時計はそれより 3日早い 7月20日になっていたということですよね。だとすると Date: は過去の日付になり、過去からのメールになるはずです。そうではなくて、「3日ほど早く時を刻んでいた」という意味だったのでしょうか？
まあ、どちらにしても私は間違えてしまったわけですが、どうして「進んでいる」「遅れている」という言い方をしないのでしょうね……？
グルメパレス
「ポポローグ (www.amazon.co.jp)
ガバスの町には、モンスターをビンに詰めて持って行くと料理を作ってくれる「グルメパレス」という施設があるのですが、これが「料理の鉄人」そのまんま。スタジアムの雰囲気もまんまですし、和食を選ぶと、さらさらとお品書きを書いて渡してくれたりします。その動きがまた細かくて、ドット絵なのにちゃんと料理しているように見えるのです。下手なポリゴンゲームよりもずっと良いですね。
2003年7月22日(火曜日)
雑多メモ
完全に内輪ネタのメモ。
- 「社屋」は「しゃや」ではなくて「しゃおく」。
- 「ゼンジンミモン」というのは「前人未踏」と「前代未聞」の混同？
- 社名を間違えるのはたぶん二度目。誰もつっこんでないから訂正されないのでしょうなぁ。
関連する話題: 内輪ネタ
やってしもうた
HTML 関係で久々に頭に来ました。asahi.com : Be on Saturday の「夏休みホームページ作り（上）」 (www.be.asahi.com)。
図【４】の４行目の＜Ｈ１＞は、見出しであることを表しています。Ｈに続く数字は１から６まで。数字が小さいほど、文字は大きく強調されます。６行目の数字は本文の文字サイズを指示しています。１から７までありますが、こちらは数字が大きいほど文字が大きくなります。見出しと本文の数字の指示の仕方が逆というのは、ほとんど嫌がらせかとも思えますが、ここは淡々と行きましょう。
以上、asahi.comの夏休みホームページ作り（上） より
※引用文中の強調は引用者による
やってしまいました。
念のため説明しておくと、h1 ～ h6 は見出しを示す要素で、1～6 の数字は見出しのレベルを表しています。このレベルは文字のサイズとは関係ありません。多くのブラウザのデフォルトスタイルが、たまたま文字サイズの変化で見出しレベルの差異を表しているというだけです。表示の仕方が逆も何も、そもそも文字サイズとは関係ないのです。
こういった基本的な概念も理解せずに「嫌がらせかとも思えます」などと書いてしまったりするような人は、もう 3年くらい前に絶滅したものとばかり思っていました。なんでこんなところで復活しているのでしょうか。
しかしまあ、このように概念を勘違いしていたり、用語がおかしかったりするのには、とりあえず目をつぶるとしましょう。許し難いのは、例として出している HTML が HTML として思いっきり間違っているということです。
例の HTML は画像になってしまっているので、テキストにして引用しておきます。
<html>
<body>
<font color="blue">
<H1><center>ホームページ講座３回のスケジュール
</center></H1></font>
<font size=5><center>
７月１９日号 まず文字だけのページから
<br>
７月２６日号 画像を張ってみます
<br>
８月２日号
</center>
</font>
</body>
</html>
「画像を張ってみます」は原文のママ (貼る?)、誤ったマーク付けもすべて原文のママです。ここを読んでいる方の多くにはもう見た瞬間に悟って頂いていると思いますが、念のため、どこがどう間違っているか箇条書きにしておきます。
- 文書型宣言がない
- title要素がない
- font要素の中に H1要素が出現 (致命的、フォロー不可能)
- H1要素の中に center要素が出現 (致命的、フォロー不可能)
- font要素の中に center要素が出現 (致命的、フォロー不可能)
まあ、titleがなかったり文書型宣言がないのは、ステップを追って解説していくうちに登場してくるのだろうと考えることもできます。しかし、font要素の中に H1 要素を入れようとしてしまっていることについては、フォローのしようがありません。
「インライン要素の中に h1 などのブロック要素を入れることはできない」というのは HTML の初歩的な知識ですが、この著者はその初歩すら全く理解していないようです。そもそもインライン要素とブロック要素の区別もついていないでしょう。
※本当はそれ以前に、font 要素や center 要素を使った 5年半も前の HTML を今教えることの意義についても検討すべきでしょうが、ここでは棚上げにしておきます。さらに、font 要素で色指定することによるアクセス性への影響などについても検討すべきですが、まるごと棚上げにしておきます。この著者に期待できる事柄でもないでしょうし。
この犯人は「『初めてＨＴＭＬに挑戦する人のためのらくらくホームページ』（かんき出版）を著した石澤義裕さんと狩野祐子さん」
なのだそうで。その本の内容が一体どうなっているのか、非常に良くない意味でとても気になります。
2003年7月18日(金曜日)
ゴミ捨て
他人様が丁寧にとって置いたゴミをひたすら捨てる作業。これがまた丁寧にクリップで留められていたり、しっかりとファイルに挟んであったりするわけなのです。かつての持ち主が几帳面であればあるほど、それらを分別するという作業はハードになるわけでして。
もう見もしない書類に無意味な几帳面さを発揮するのはやめて、要らなくなった書類はさっさと捨てて頂きたく願う所存にございます。
私は
更新: 2003年8月25日
えー、この日記の作者は「水無月ばけら」です。「えび」じゃないのです。
「えび日記さん」と呼んでくださる方がいらっしゃいますが、「中禅寺」という姓の人を「京極堂」と呼んだりするのが間違いでないとするなら、別に間違ってはいないのかもしれません。昔は「鳩丸さん」というのもありましたし……。
※2003-08-25 追記 : ごめんなさい、京極堂さんは「中善寺」じゃなくて「中禅寺」さんでした。謹んで訂正させて頂きます。名前を間違ってるという話題で自分が間違ってどうする。 > わたし
ちなみに、「何でえびなの？」というのは FAQ です。昔は「読めばきっと分かります」と回答していたのですが、それで分かったという人はむらまささんくらいしかいないようで。
※恐ろしく端折って説明すると「水無月英水子」→「えみこちゃん」→「えみちゃん」→「えびちゃん」という出世魚ぶりが発揮された結果なのですが、現在では枝分かれ進化した愛称が使用されているので、少女時代を知らない人には謎となっています。……って、この説明で分かる人も少ないような気がしますが。
関連する話題: えび日記
2003年7月17日(木曜日)
META Refresh に依存したダウンロード
Adobe のサイトで Adobe Reader (旧名 Acrobat Reader) をダウンロードしようとしたら、こんな画面が。
Adobe® Reader® (無償配布）をダウンロードいただき、ありがとうございます。
全く意味が分かりませんでした。まだダウンロードしていないのにそう言われても……。そのページからダウンロードへのリンクがあるのかと思いましたが、探しても見つからずに途方に暮れ……嫌な予感がしてソースを解読すると、META Refresh でした。もうね。
というわけで入手できました。JavaScript 無効は考慮しているのに META Refresh に依存しているという詰めの甘さが、ある意味 Adobe らしいというかなんというか……。
関連する話題: アクセシビリティ
fieldset
MS03-026 (www.microsoft.com)の HTML には fieldset要素が使われているのですね。
これがまた視覚効果を狙ったとしか思えない微妙な使われ方……というか、よく見たらそれ以前にきっぱり文法違反でしたね。
※実は DTD 的にはフォームコントロールを入れなければならないことにはなっていないのですが、それ以前に li要素の使い方などが致命的に間違っています。
関連する話題: HTML
ミニ雪だるま紛失
一段落したので、ひそかに買っていた「ポポローグ (www.amazon.co.jp)
ポポロクロイスシリーズは「ポポロクロイス物語2 (www.amazon.co.jp)
開始するとピエトロの部屋なので、速攻で隠し部屋に行って宝箱をあさり、昔のおみやげを回収。未来のおみやげが回収できないのは当然ですが……ミニ雪だるまがありません！
ぽちっとリセットしてメモリーカードを調べてみると、「ポポロクロイス物語」のセーブデータはひとつしか残っておらず、それは第四章の白い村。どうも、ミニ雪だるまを持っているデータは消してしまったようなのです。
おみやげですからゲームの進行には全然関係ありませんが、なんとなく据わりが悪い感じです。取りなおすべきか、取らざるべきか、非常に微妙……。
※どうでも良いですが、雪だるまが溶けずに何年も残っているというのも凄いですね……。魔法かなにかで保存しているのかしら。
新・タグ使用機能
そんなわけで、解禁された Web フォーラムのタグ使用機能について調査。あんまりちゃんとは調べていないのですが……。
- <script> などは削除されます。
- 属性値リテラルに "javascript:……" という文字列があると "java-script" に置き換わります。これはイベントハンドラのみならず、title属性や alt属性にすら適用されます (見境ないですが、その方が安全ではあります)。
- タグの対応関係は考慮していないようで、<b> とだけ書いた発言をすると b要素の開始タグだけが書かれます (Well-formed になりません)。
- NUL文字があると、そこから後ろはちょん切られます。
- <foo> などの未知タグはサニタイズされる模様です。ホワイトリスト採用？
- 未知属性を含むタグは、属性をすべて削除した上でサニタイズされる模様。削除することの意味が全く分かりませんが、危険はないでしょう。
というわけで、これだけ見ると、HTML の話題に支障が出そうな気はするものの、危険はなさそうです。
しかしながら、Cookie のドメイン問題については特に修正されていないようです。hpcgi1.nifty.com や enter,nifty.com で Cookie が読み取れてしまいます。そこへ来て、
という状態が加わりましたので、Cookie ドメイン問題によるセッションハイジャックの危険性は跳ね上がってしまったのでありました。
2003年7月16日(水曜日)
解禁?
15日のメンテナンスで Web フォーラムのタグ使用が解禁されたようですね。16日もメンテナンスをするというアナウンスが出ていますので、全フォーラムで解禁されたのかどうかは良く分かりません。
いずれにしても特定タグだけのサニタイズを試みているような雰囲気ですので、突破できてしまう可能性が残されています。本当に安全になったと言えるのかどうか検証したいのですが、ちょっと忙しくて時間がとれず……。
2003年7月15日(火曜日)
ポイント還元
「悪徳商法？マニアックス (www6.big.or.jp)」の「悪の最新情報 (www6.big.or.jp)」に、ビックカメラのポイントの話が出ていますね。
とりあえず、ビックカメラのレシートで使用されるグロッサリ。
- 小計 …… 購入した品物の価格の和。ただし消費税を含みません。
- P値引 …… ポイントを使用することによって値引きされた金額。ポイントをためる場合はこの値は 0。
- 対象額 …… ポイント加算の対象となる金額。「小計 - P値引き」で求められます。
- 今回サービスP …… 今回の買い物によって加算されたポイント。「対象額 × ポイント係数」で求められ、端数は切り上げです。
注目すべき点は、
- サービスP は端数切り上げ。
- 対象額からは P 値引き分が引かれている。つまり、ポイントで買った分はポイントの対象になりません。
前者により、「対象額が端数になると得する」という結論が導かれます。「こまめに使うと得をする」のは、こまめに使うと端数が出やすいからです。端数が全く出ない場合は、こまめに使っても結果は同じになります。
※とは言っても、端数が出たときに得するのは 1回で 1ポイント (1円相当) なので、このためにわざわざレジに 2回並んだりする気にはなりませんが……。
実は後者が重要です。まず、ポイント還元率が高いものを買うときにはポイントを使わない方が良い、ということは明らかですね。
そして重要なのは、ポイント 10% の還元が 1割引相当にならないということです。たとえば、9000円のものを買ってポイント 900 を貯め、そのポイントで 900 円のものを買うとポイントはちょうど 0 になります。10000円分を 9000円で買えたのなら 1割引相当になりますが、9000円では 9900円分しか買えないのです。ポイントが 10% つくのは 1割引と同じ……と思いがちですが、実際にはおよそ 9.1% 割引相当でしかありません。
※ちなみに消費税を考慮しても還元率は同じです。
※ポイントで買った分にもポイントがつくならば、これはちゃんと 1割引相当になります。ただし、その場合は手元のポイントを使い切ることが不可能です。また、この場合に仮に 1円相当の品物が存在すると、1ポイントで1円の品物を買ったときに 1ポイントつくことになるので、無限大に還元が得られることになってしまいます。
……とまあ、こういう話なのですが、面白いと思ったのはポイント 10% が実は 1割引相当ではない、という数字トリックです。これ、闇金融などが利息をあらかじめ引いて貸し付けるという話と似ているのですね。
たとえば、利息 10% と称してまず 10000円を見せ、利息を先に引いて 9000円を渡し、10000円を返済させるようなことがあります。このとき、実質的には 9000 円を借りて 10000 円を返していることになりますから、利息は 10% ではなく、約 11.1% となっているわけです。
※これは「ナニワ金融道 (www.amazon.co.jp)
2003年7月14日(月曜日)
.NET ドキュメントコメント
C# のソースには XML のコメントを書くことができたりします。で、コンパイル時にオプションを指定すると XML のドキュメントが出力されるのですが、これをブラウズする方法ってないものなのでしょうか。
むらまささんに「ドキュメントちゃんと読め！」と言われたので読んでみると、
これで、XML ファイルの XMLsample.xml が作成されます。このファイルは、ブラウザや TYPE コマンドによって参照できます。
以上、MicrosoftのC# プログラマーズ リファレンス XML ドキュメントのチュートリアル より
というわけで、ブラウザで XML をそのまま読むとか、TYPE コマンド (!) でテキストとして読むという方法が出ていますが、加工して云々という話はどこにも。Visual Studio があるとカッコいいことができるのであろうなぁとは思いますが。
……やっぱり自分で XSLT を書くか、それともこれを処理するプログラムを C# で書くかしたほうが良いのかしら。既存のものがありそうな気がするのですが……。
セキュリティホール話追記
「@nifty パレットのセキュリティホール まとめ」に追記。パレットを全く利用していなくても、ID とパスワードが盗まれる可能性があります。
2003年7月13日(日曜日)
蕎麦「たなか」
美味しいらしいと言う話を聞いて、「たなか」という
※Web でも「たなか 蕎麦」とかで検索するとそれなりにヒットしますね。
というわけでお食事ですが、なかなか素晴らしいお味でした。蕎麦はもちろん、天ぷらも good。何気なく薬味が辛味大根だったりしてニクいです。
なお、このお店は店内全面禁煙のようなので安心です。
関連する話題: 飲食物
2003年7月12日(土曜日)
鳩丸高速化計画
というわけで hatomaru.dll 高速化計画第一弾。
最近 hatomaru.dll が遅い気がしているわけですが、実はその原因のひとつは既に分かっています。コメントの数が増えたからです。コメントが増えると日記の表示は遅くなります。
コメントを表示しなければ関係ないのでは……と思うかも知れませんが、そうではありません。日記の各トピックには、ついているコメントの件数を表示しているからです。件数を表示するためには、コメントの数を数えなければなりません。
※見出しが付いたひとまとまりのことを、内部ではトピックと呼んでいます。そのまんま Topic というクラスになっています。
実は今まで、このルーチンに関してはほとんどなにも考えませんでした。あるトピックについているコメントの数をカウントする際は、GetCommentCount というメソッドを呼んでいます。そのメソッドの内容は以下のような処理になっています。
- コメントの XML ファイルが読み込まれていなければ読んで、topic要素だけを抽出した XmlNodeList を用意しておく。
- ひとつひとつ XmlNode を読んで、そのトピックの URL とコメント先の URL が一致するか判定する。
- 一致していたらカウンタを増やす。一致しなければ何もしない。
- 読み終わったらカウンタの数字を返す。
まあ特に何も考えていないのですが、恐ろしいのはここからです。ひとつのページ内に複数のトピックが表示される場合は、何も考えずにトピックの数だけ GetCommentCount が呼ばれます。XML ファイルのロードは一回しか行いませんが、XmlNodeList のサーチは表示されるトピックの数だけ繰り返されることになります。ページ表示の際に「URL が一致したか」という判定が何回行われるかというと、これはトピックの数×コメントの総数、となります。これはトピックが少ない場合、あるいはコメントが少ない場合にはほとんど問題ありませんが、両者が増えてくると大変なことになります。
……というわけなので、このアルゴリズムをちょっとだけ見直しました。具体的には、以下のような処理を入れています。
- 最初の XML ロード時にある程度振り落としておく。たとえば、えび日記を表示するのなら、ぐろっさりに対するコメントは必要ない。
- あるトピックのコメントであると判定された要素は他のトピックのコメントではあり得ないので、リストから削除する。
これだけですが、それでもトピック数が多いときの処理速度はかなり向上したはずです。特に、話題別で数の多いトピックを表示するときなどに効果が大きいかも。
※ただし、内部キャッシュがある場合の速度は変わりません。また、当然ですがコメント投稿機能実装以前の速度には及びません。
とは言え、これでもコメントの件数が増えればやっぱり遅くなります。根本的に異なる方法、たとえば、投稿するときに数えてその結果を保存しておくとか、そういった方法の方が速くなるような気はします。まあ、あまりにも遅くなったら、その時にまた考えましょう。
関連する話題: えび日記 / hatomaru.dll / 鳩丸高速化計画
2003年7月11日(金曜日)
元の木阿弥
えー、昨日一度変更した日記 URL の仕様ですが、元に戻しました。
理由は単純で、リクエストがタイムアウトしちゃっているログが十数件観測されたからです。どうも GetHashCode は私が思ったより大変な作業みたい。
というわけで、元に戻します。新しい URL でリンクしてしまった方には申し訳ありませんが、その URL は無効になります。
……そんな感じで、そろそろパフォーマンスについて考える時がやってきたようです。勉強しないと……。
関連する話題: えび日記 / hatomaru.dll
有害フィルタ
セキュリティホールmemo が有害情報データベースに登録されたという話ですが、情報がいろいろ寄せられているようですね (参照: セキュリティホールmemo 2003.07.11 (www.st.ryukoku.ac.jp))。
IP アドレス指定なら見られるというのは面白いです。バーチャルドメインだと不利なのですね。
まあそれは置いておくとして、「大量破壊兵器」というキーワードだけで登録されてしまうらしいという話。反射的に "Internet-Html-Searcher" を連想したのは私だけでしょうか。最近見なくなりましたが、「robotはぢきについて」の該当部分 (c-moon.jp)などを見ると User-Agent を偽装して活動を続けているという話のようで、何だかなぁという感じではあります。
※Internet-Html-Searcher は、「i フィルター」というフィルタソフトを作っているデジタルアーツという会社のロボット。その評判については、まあ Internet-Html-Searcher で検索すれば分かると思います。
ちなみに、私の手元ではそれらしきものが 3件該当しました。
2003-04-16 08:57:58 61.115.195.181 GET http://altba.com/bakera/hatomaru.aspx/htmlbbs 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) http://altba.com/bakera/hatomaru.aspx/htmlbbs
2003-04-17 01:58:39 61.115.195.181 GET http://altba.com/bakera/hatomaru.aspx/ebi/2003 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) http://altba.com/bakera/hatomaru.aspx/ebi/2003
2003-04-29 13:09:36 61.115.195.179 GET http://altba.com/bakera/hatomaru.aspx/htmlbbs 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) http://altba.com/bakera/hatomaru.aspx/htmlbbs
4月以降は来ていないようですが、リモートホストを変えているだけとかいう可能性もありますし……。リクエストしている URL と Referer が一致するものは警戒してみようかしら。
……今は亡き Some Gripes on User-Agent を Web Archive から引っ張り出して該当部分を参照 (web.archive.org) してみると、いやはや実に詳しいですね。Internet-Html-Searcher という名が使われていたのは一時期に過ぎず、またデジタルアーツは複数のネットブロックを持っていらっしゃるのだそうで。
※おまけ (いずれも Web Archive から発掘) : ある日突然 (web.archive.org) / 385万ヒットに潜むリスク（「知らなかった」では済まされない） (web.archive.org) / その２のクイズの答 (web.archive.org) / 報告書 (web.archive.org)。企業名は伏せてあっても URL から丸わかりという……。
駆除済み
こんなの来ました。
これは、富士ゼロックスのウィルス検知システムが自動挿入した情報です。 あなた(またはあなたがメンバ登録されているメーリングリスト)宛のメールに 添付されていたファイルからウィルスを検出しました。 ウイルス感染防止のため、システムは受信メールの添付ファイルを取り除きました。 <富士ゼロックスグループのイントラネット外で本メールを受信された方> 本メールはウイルス感染した添付ファイルを除去しておりますので、 ウイルス駆除の必要はございません。 <富士ゼロックスグループのイントラネット利用者> 下記URLにアクセスし、対応をおこなってください。 http://virus.ssc.fxhq.fujixerox.co.jp/interscan/rcvmsg
このメッセージはメールの添付メッセージの一部で、メール自体は sgml@fxis.co.jp が User Unknown であることを通知する DSN のようです。おそらくこんなシナリオではないかと思います。
- どこかの誰かが (おそらくは知らぬ間に感染していて) エンベロープ From に私のメールアドレスが入ったウィルスメールを sgml@fxis.co.jp に宛てて送信。
- sgml@fxis.co.jp は User Unknown だったので、元メールを添付した上でエンベロープ宛てに DSN を返送しようとした。
- ウィルスチェッカが添付された元メールからウィルスを検出。
- ウィルスパートが警告文に置き換えられた DSN が私のところに送られてきた。
まあそれはそれで問題ありませんが、知らない人が見たら「富士ゼロックスの誰かが自分にウィルスメールを送ろうとしたのか!?」などと誤解しそうな気はしますね。
2003年7月10日(木曜日)
wfetch
ちょっと前にむらまささんに教えてもらったものですが、ちょっとメモしておきます。
[HOWTO] Wfetch.exe を使用して HTTP 接続のトラブルシューティングを行う方法 (support.microsoft.com)
関連する話題: メモ
URL変更とか
えび日記の個々の見出しを指定する URL が長すぎる気がしたので、ちょっと URL の生成方法を変えてみました。以前は UTF-16 のビット列を 16進数にしたものを使用していましたが、それを単純に Math.Abs(title.GetHashCode()) に変えました。
ハッシュコードの絶対値の範囲は 0 ～ 21億4748万3647 の間ですので、これがたまたま一致してしまうと誤動作する可能性があります。しかしまあ、まず発生しないと考えて良い確率でしょう。
これでまあ URL も多少使いやすくなったのではないかと思います。なお、従来の URL でも参照できるようになっていますので、特にリンク張り替えの必要などはないはずです。
関連する話題: えび日記 / hatomaru.dll
2003年7月9日(水曜日)
プライベートgooで他人のサーバに繋ぐ
更新: 2005年4月21日
某所で稼働しているプライベートgoo (private.goo.ne.jp) を使って altba.com のポート 25番を襲わせてみたら、見事に成功。
実はプライベートgoo では、CGI の稼働しているサーバと検索のデータベースを持つサーバとが分かれています。そしてここからが凄いのですが、検索データを拾ってくるサーバの名前とポート番号は、フォームのパラメータで指定するようになっているのです。そのため、これを適当な値に設定して POST してやると、CGI の稼働しているサーバは、任意のサーバの任意のポートに接続しに行ってくれます。
※正確には「分かれている」のではくて「分けることができる」で、たいていの場合は localhost に接続しに行くように設定されています。
※外向きの怪しいパケットはファイアウォールでフィルタされそうなものですが、CGI の動いているサーバが DMZ に置かれているためなのか、プライベート goo のこれがフィルタされたケースは見たことがありません。
これ、去年の3月に別の場所で気づいてちょっと気になっていたのですが、未だにそのままなのですね。とりあえずファイアウォールの状態確認に使えたり、DoS に使えたりする可能性がありますが、それほど問題ないのかしら。
※2003-07-10 追記 : これ、よく考えたら私が自ら気づいたのではなくて、keitap (blog.keitap.com) さんに教えてもらった情報でした。
まあ、考えてみると Another HTML-lint のようなものだって任意のサーバの任意のポートにつなげたりするわけですし、それはそれで特に問題ないような気もしますね……。
※2004-11-18 : 諸事情により内容を非公開としました。
※2005-04-21追記 : 最新バージョンで修正されたようです。内容をふたたび公開しました。
入力欄が泣き別れ
「使いやすさ日記『168. ブロードバンドのエリア・チェック』 (usability.novas.co.jp)」。電話番号の入力フォームが三つに分かれていて使いにくい、という話がありますが、同感です。ペーストできませんし、IME に覚えさせておいても一発入力できません。
実はもう一つ、HTML として致命的に問題になる点があります。それは、後の入力欄にラベルがつけられないこと。全てのフォームコントロールにユニークなラベルをつける必要がありますが、三つまとめて「電話番号」というラベルは付けられても、入力欄一つ一つにラベルを付けることができないのですよね。
※一応、それぞれ「市外局番」「市内局番」「お客様番号」という呼称があるので、つけようと思えばつかないことはないのですが。
では分けることにメリットはないのかというと、そうでもありません。使いやすさ日記にはこう書かれています。
ひとつだけメリットがあるとすれば、「ここは電話番号いれるところ！」ってのが見えとしてアピールしやすいというのはありますね。
ひとつだけと言われていますが、そんなことはないでしょう。入力欄が一つだけだと、電話番号入力の際の書式に迷う可能性があります。"000-0000-0000" とハイフンで区切れば良いのか、000 (0000) 0000 と括弧でくくるのか、それとも 00000000000 と全部つなげれば良いのか……。入力欄が分かれていれば、ここで迷うことがありません。逆に、入力欄を一つにする場合は、どこかに入力例を書いておく必要があるでしょう。
あともう一つ、市外局番や市内局番が分かれていると、システムのデータ処理に都合が良い場合があります。一つにしようと画策してみても、サーバ側システムの要請で「入力欄を分ける必要がある」と言われてしまうことがあったりしますね。
とは言うものの、個人的にはやっぱり入力欄は一つの方が好きだったりします。
ISP に連絡する話
「なんとなくかくにっき (www.mtaka.com)」がいろいろなところで話題になっているようですね。しょぼい書き込みのアクセスもとを追跡して、お灸を据えたという話。
論点はいろいろあるようですが、「最初から ISP ではなくて高校に連絡するべきだったのではないか」という意見は、サーバ管理者としては傾聴に値しますね。確かにそれが筋のような気はします。仮に OpenProxy 状態だったとしても、ISP では高校のサーバの設定を変えたりできないでしょうし、ISP 側で対処できるようなことはほとんどなかったのではないかと思います。まあ、最終的には高校と連絡を取って解決したわけですから、それはそれで問題ないような気もしますが。
……ISP に連絡といえば、ずっと昔にリムネットに連絡した時のことを思い出します。今でこそ ISP に連絡するなんて平気の平左衛門ですが、その時はよそのサーバ管理者にコンタクトを取ったことがなかったので、だいぶ緊張していました。
りゅうさんの日記を見ると、もう2年以上も前の話なのですね。
某ドメイン(何処)宛にメールが送れないと某管理者(誰)に泣きついてみたら、なんと、rim-netのメールサーバがORBSのブラックリストに載ってしまったという衝撃の返事が。簡単に言うとSPAMの中継元として認定されてしまったので、ORBSのデータベースを利用してSPAM除けをしているメールサーバにはメーれなくなってしまうのだった。
ということで某管理者(誰)がrim-netにメーってくれた模様。なにしろroot@なメアド。強力だ!(謎)。
以上、りゅうさんの偽偽夜食日記の部屋2001年5月 より
ええメーりましたとも。私の側の記録を見ると、5月21日に「対応完了」という連絡があって平穏無事に解決したようです。対応が思ったよりも素早く、感心した記憶があります。今は亡き ORBS のことといい、懐かしいですね。
……とまあ回想はこの辺にして、せっかくなので 7月8日の日記に反応してみたり。
ime.nuあたりから来る人達(2chのスレ)ってさほどいなかったみたいで大した事はありませんでした。もっともリファラーなんてすぐ消せるのでどうって事無いんですけど。/.Jで話題になった瞬間からすごいアクセスが。
以上、takahataさんのなんとなくかくにっき(2003-07-08) より
私もちょっと前に似たようなことを経験していますが、2ch からのアクセスが予想よりもずっと少なくて驚きました。ブラクラを警戒してリンクをたどらない人が多いという話なのかも知れませんが、それにしても少なかったですね。思ったほどは読まれていない (書き込みの量に比して ROM の割合が少ない) のかも知れません。
2003年7月7日(月曜日)
パレットのセキュリティホールまとめ
全然タイムリーではありませんが、何となくまとめてみました「@nifty パレットのセキュリティホール まとめ」。
2003年7月6日(日曜日)
ピタゴラスイッチ
どうも、ピタゴラスイッチ (www.nhk.or.jp)があんまり認知されていないようで残念な思いをいたしました。「アルゴリズムたいそう」なんか大人が見ても面白いと思うのですが。
……「アルゴリズムたいそう」で検索したら、スラッシュドットでも話題になっていました (slashdot.jp)。何でみんな知らないんだろ。
XML を利用して XSS
どこかで何かが成功してしまったという話ではありませんが、単にメモとして。
とりあえずこんなのを思いついたので試してみました。
<?xml-stylesheet type="text/xsl" href="javascript:alert('foo');" ?>
しかし、これは MSIE6 では動作しませんでした。あと、XSL ファイル内に以下のように書く方法も思いつきましたが、これも駄目でした。
<xsl:include href="javascript:alert('foo');"/>
では xml-stylesheet 処理命令は安全なのかというとそうでもありません。以下のようにするとスクリプトの実行が可能です。まず、
<?xml-stylesheet type="text/css" href="test.css" ?>
と書いておいて、test.css に
@import url("javascript:alert('foo');");
と書けば OK。MSIE6 で動作を確認しました。
最近のブラウザは XML 系のもろもろに対応していたりすることがあるので、深く研究してみると面白いかも知れません。
2003年7月5日(土曜日)
ASP.NET は Authorization フィールドが読める
Basic 認証では HTTP 要求ヘッダの中に Authorization というフィールドが出力され、ID:パスワードを Base64 エンコードしたものが値として送出されます。このフィールドは Apache の CGI からは読むことが出来ません。これはセキュリティ的な配慮で、Authorization フィールドの値が環境変数の値として CGI に渡されると、それが外から読まれてしまう可能性があるためです。
ところが ASP.NET にはこのような制限がなく、Authorization フィールドも他のフィールドと全く同じように読めるようです。Request.Headers["Authorization"] を参照すると、何の問題もなく取得できてしまいます。自ら 401 を返して任意の ID とパスワードで認証するようなことも出来て、便利は便利です。
※ちょっと頑張れば Digest 認証も実装できそうですね。クライアント側が対応しているかどうかは謎ですが。
しかし、これはちょっと気をつけておく必要があります。ユーザが任意の ASP.NET のリソースを使用できるようなサーバで Basic 認証を使っていると、その ID とパスワードを別のユーザの ASP.NET によって読み取られてしまう可能性があります。
最少リンクプレイ断念
リーヴェルファンタジア (www.amazon.co.jp)
結局、ミスリルなどは拾えず苦戦しつつも借金返済してクリア。
そして9月。「つのだ☆ひろ」ならぬ「ザ☆スカイ」のお話。リペアキッドがいないと話が進まないので誕生させ、その後ヘリバンブーも誕生させて風の迷宮へ。
風の迷宮は慣れないとどこをどう進んで良いのか分からなかったりしますが、慣れていれば楽勝です。ケインフォックスに会って牢獄の封印を解き……。
……って、封印が解けないですよっ!?
何度試しても、「あんたみたいなチビには無理だ」などと言われて解けません。先にパーンを助けてみましたが、状況変わらず。初回プレイでは、特に何かしなくてもいきなり封印が解けたような気がするのです。そうなると、思い当たるのは妖精とのリンク数が一定以上になっていないと封印が解けないという可能性。まだリンク数 30ちょいのフェアリーサモナーですから、力不足ということなのかも知れません。
……妖精とリンクしまくれば進めるのかも知れませんが、それでは最少リンクプレイの意味なし。よって最少リンクプレイはここにて断念、と相成りました。
関連する話題: ゲーム / リーヴェルファンタジア
2003年7月4日(金曜日)
増粘多糖類
「増粘多糖類」というのは何かそういう食品があるわけではなく、増粘安定剤として複数の多糖類を使用している場合にそういう表示が認められるのだそうで。
たとえば、ジャムに高確率で入っている「ペクチン」は増粘安定剤として使用される多糖類の一種です。単独なら「ペクチン」と表示されるわけですが、別の種類の多糖類も増粘安定剤として使用しているなら、まとめて「増粘多糖類」と表示できると、こういうわけです。
パレット系
なんだか良く分かりませんが、いつのまにやらパレットのサニタイズのルーチンが変わっているようで、以前できたサニタイズ回避方法が通用しなくなっているようです。
しかし、その代わりに以前はできなかった別の回避方法が通用するようになっています。何が起きたのか良く分かりませんが、状況は変わっていない感じですね。
※しかも、ゴミが出ない美しい書きかたが出来るようになったという……。
それはそれとして、パレットにおいてもう一つ別のスクリプト書き込み方法を発見しました。そもそもはこれができてしまうかどうかテストしようとしてアクセスしたのですが、予想通り出来てしまうようです。こちらはサニタイズ一切無しで完全にノーチェックなので、策も何も無しに貫通します。
やっぱり一筋縄では行かない感じ。
.NET Framework SDK 1.1
手元の SDK ドキュメントの内容と Web 上の MSDN ライブラリの内容が何か食い違うのでおかしいなと思ったら、.NET Framework 1.1 で変更になっている部分だったようです。
というわけで、手元にも .NET Framework SDK 1.1 をインストール。1.0 と共存してしまうのがちょっと鬱陶しいですが、side-by-side 実行とか何とかがあるので、あえて共存させたまま置いておくことにします。
悲哀の7月
リーヴェルファンタジア (www.amazon.co.jp)
※ここの水晶のようなトゲトゲに当たると何故か一撃死することがあるのですが、慣れれば余裕で回避可能なので問題なしです。
というわけで軽々とクリア。月の妖精から「月のしずく」をもらいます。一度最後までプレイしていると、ここで月の妖精の言っていることの意味がはっきりと分かり、悲しくなります。この後のシーンも含め、2周目の 7月はやるせない気持ちでいっぱいになりますね。
ついでにここで、ルーキーテイマーだったマリエルがフェアリーサモナーにランクアップ。
あとは借金だけですが、そろそろジェネテリアの原料が少なくなってきました。虹の結晶はたくさんあるのですが、珊瑚の岩が不足気味。まあここで使い切ったとしても、8月は水晶鉱山ですから、うまくミスリルが拾えたりすれば借金苦から解放されそうではあります。
関連する話題: ゲーム / リーヴェルファンタジア
2003年7月3日(木曜日)
SP4
Windows 2000 SP4 を適用しました。
再起動するとブルースクリーンで……なんてこともなく、特に問題はないようです。ただ、再起動直後にこんなイベントが残っているのがちょっとだけ気になります。
次の無効なリターン コードが返されたため、WMI ADAP は Spooler パフォーマンス ライブラリを読み込むことができませんでした: 0x80041001
プリンタなんか繋がっていないし、Spooler は関係なさそうなのではありますけれど……今までこんなログが残ったことはないのですよね。微妙に不気味。
関連する話題: Windows 2000 / サーバ / altba.com
XSS大王の傾向と対策
更新: 2003年7月4日
こんなんでました。
いつもフォーラムをご利用いただきましてありがとうございます。
本日（7/3） のメンテナンスにおいて、まずは、掲示板（セミオープン／会員限定）へ新規に発言やコメントの登録をする際、一部のHTMLタグの記述を制限する対策を行いました。制限をしているタグなど詳しくはこちらをご覧ください。
また、この後、引き続き、これまでに登録された発言やコメントについての対策を行う予定です。そのため、全ての作業が終わるまでの間、新規発言やコメントで、タグが利用されていた場合には、そのまま表示されることとなりますのでご留意ください。
なお、機能再開の時期につきましては、現在、 7月末の見込みですが、具体的な日時が判明次第、ご案内申しあげます。
ご迷惑をおかけし、申し訳ございませんが、何卒ご理解賜りますようお願いいたします。
以上、https://com.nifty.com/forum/ より
サニタイズを強化したけれども、既存の発言はそのままなので注意ということらしいです。もちろん、既存の発言の中に罠が含まれていないかは精査しているのでしょうね。
※と、信じたいですけれど。
では早速サニタイズぶりを検証……と思ったら、掲示板の方はまだメンテナンス中のようで残念な思いをいたしました。アナウンスを更新したタイミングで何かが発生したのかしら。
18:45 頃に確認したら掲示板は復旧していました。でも何の属性もついていない b要素すら書けませんね。アナウンスの日本語がイマイチ意味不明なのですが、7月末までは一切のタグが書けないということなのかも知れません。※だとすると、今日行われたのが何だったのか良く分からないのですが……。
2003-07-04 追記 : 「Web 快適活用フォーラム」に分かりやすいアナウンスが出ていました。
上記の内容では、使用できるタグが制限されるものの、もう使えるようにも読めますが、実際には、まだ全面禁止のままです。
それだけではなく、タグとしての動作が禁止されているにもかかわらず、上記の制限がされるという、大変、困惑する状態となってしまいました。
例えば、制限されるタグである「＜ｈｔｍｌ＞」を半角で記述すると、今までは無効なタグでしたので、そのまま、表示されていましたが、現在は削除されてなくなってしまいます。
従って、スタイルシート指定どころか、html文書の記述も、ほぼ不可能となってしまっています。
この処置は、７月末までの暫定的なものとのことですが、８月以降もタグ有効な掲示板においては、制限されたタグの記述は削除される模様です。
以上、http://bbs1.nifty.com/mes/cf_wrent/FWEBKK_B001 より
ということだそうで、いろいろな意味で頭が痛いですね。
2003年7月2日(水曜日)
TRACEメソッドをブロック
TRACE メソッドって URLScan のデフォルトの設定でブロックされるようになっているんですね。こんなログが残りました。
Client at 211.16.234.154: Sent verb 'TRACE', which is not specifically allowed. Request will be rejected.
ちょっとだけ IIS の株が上がりました。
※って、URLScan 自体 IIS のデフォルトではないのですけれど。
サニタイズ貫通(XSS大王シリーズ)
更新: 2003年7月4日
nifty.com 以下のドメインには「パレット」というサービスがあります。この名前からサービスの内容を想像するのはかなり困難ですが、要するに「絵が描ける掲示板」というようなコンセプトだったようです。つまりは HTML タグが使用できる掲示板です。
私は把握していなかったのですが、かつてはこれにも自由にいろいろ書けてしまったようで、6月30日に、パレットのタグ利用を制限した旨のアナウンスが出ています。
パレットでのタグの利用について
パレットでのタグの制限につきましてご案内が遅れましたこと、お詫び申し上げます。今回パレットを安全にご利用いただけるよう対応をおこない、一部のHTMLタグの記述を制限させていただきました。
この制限はブラウザでの発言の表示となります。ニュースリーダーでのアクセスでは、オリジナルのデータを取得することとなります。
詳細は「パレットの基本仕様」または「よく使うＨＴＭＬタグ」をご参照ください。
引き続き、みなさまに安心してご利用頂けるよう努力いたしますので、今後ともどうぞよろしくお願いいたします。
以上、https://com.nifty.com/forum/ より
というわけで、サニタイズが強化されたようです。
ところがどっこい、このサニタイズを貫通する書き方があって、なんと script要素を含む発言ができてしまうことが判明。
※具体的な方法は伏せておきます。ヒントとしては、サニタイズのルーチンが賢いのが逆に敗因になった感じ。特殊な制御文字なども不要ですし、やり方さえ分かれば誰でも気軽に書き込めます。
……どこかで高木さんも書いていたような気がしますが、「特定のタグだけのサニタイズ」って本当に難しいものですね。
なお、パレットの認証は Basic 認証で、Cookie は関係ありません。パレットだけを使用している分には、セッション Cookie の漏洩はありません。また、ここに書けるのは会員だけです。
ただし、会員がコミュニティなどにログインし、そのままパレットを閲覧すると危険な場合があります (これは Cookie ドメイン問題の影響)。また、普通に書いても img要素で外部の画像を参照することはできるので、Web バグを使用したり、ひそかに hpcgi1.nifty.com の画像を参照して Cookie を取得したりすることは可能です。
……などということをのんきに考えていましたが、実はそれだけではなく、Microsoft.XMLHTTP で Basic 認証の ID とパスワードをこっそり盗めるので、きわめて危険です。実際に Base64 エンコードされた ID:パスワードの組が画面に表示されることを確認、デコードしたら簡単に ID とパスワードが取り出せました。分かると思いますが、この値を密かに他のサーバに送出することも可能です。本気で洒落になりません……。
※Microsoft.XMLHTTP でパスワードが盗めるという情報はえむけいさんから頂きました。情報感謝です。これについての詳細は、高木さんによる「[memo:5237] XSS脆弱性によりBasic認証のパスワード情報が漏えいする (memo.st.ryukoku.ac.jp)」を参照してください。
※また、Mozilla などでも XMLHttpRequest を使用すれば全く同様にパスワードが盗めるようです。Flash や Java Applet でも OK なようで、スクリプト無効でも駄目っぽいです。この辺まとめてえむけいさん情報。
さらに恐ろしいことに、パレットには任意のファイルを添付ファイルとして指定できる機能があります。この添付ファイルは同じドメインのサーバ内に格納されます。そして発言には object要素を書くこともできてしまうので、ユーザのセキュリティ設定によっては任意の ActiveX コントロールを実行することさえできます。
※実際にこの方法で Flash を実行できることを確認しました。
これはスクリプト無効でも駄目なので、パレットには近寄らないのが無難でしょう。
2003-07-04 追記 : 「私は把握していなかった」と書きましたが、パレットに何でも書けてしまうということは公開当初から知られていたようです。「パレット裏マニュアル (forum.nifty.com)」に、パレットの発言をフレームにして他のリソースを丸ごと取り込む方法が紹介されています。今回の修正が行われる前は、文字通りの意味で何でも書けたようですね。
※FPROG 会員なのに気づいてなかった私って……。
振り返ればロボット
ログファイルが大きいなぁ、と思ったら UA 統計のトップを独走する dloader のお姿。とほほ……。
※アクセスの勢いが凄い上に、このサーチエンジンでは UTF-8 のリソースはまともに検索できないので、dloader の訪問には何のメリットもなくてひたすら
次点の ZyBorg って聞き慣れない名前でしたが、LYCOS のロボットなのですね。……ってこれもロボットかい。
……そして、そのようなログが残った後には必ず Google で "dloader" を検索した人の訪問があるのですね。笑える話なんですが、苦笑に近いなあ。
ジェネテリアを確実に合成する方法
リーヴェルファンタジア (www.amazon.co.jp)
- 電源投入直後にまっすぐエリックのところに行ってジェネテリアを合成する。
すると 100% 成功します。いわゆるひとつの「電源技」ですね。
ちなみに、そのまま続けると 3連続で失敗するのですが、ここで一度手頃なダンジョンに入ってランダムマテリアルを一つ拾い (ゴミでも可)、すぐに帰ってジェネテリアの合成をするとこれまた成功します。その後はちょっと安定させる方法が見つからず……。
この方法でジェネテリア 2個を確実に合成できます。そうしたらリセットして (ソフトリセットはたぶんできないのでハードウェアでリセット) 同じことを繰り返すと、失敗せずにジェネテリアを合成し続けられるというわけです。これはなかなか効率が良い感じ。
※ただし、ソフトウェアのバージョンやシリアルによって乱数系列が異なる可能性があるので、環境によっては再現しないかも知れません。
そんな感じでジェネテリア 10個ほど合成し、6月クリア。
関連する話題: メモ / ゲーム / リーヴェルファンタジア
2003年7月1日(火曜日)
System.Drawing.Bitmapで画像が読めない?
hatomaru.dll には System.Drawing.Bitmap のコンストラクタにファイル名を渡して PNG 画像を読み取るルーチンがあります。が、これが何故か画像によってうまく行かないことがあります。ペイントや ViX では普通に表示できる画像なのに、コンストラクタの中で「パラメータが無効」とかいう例外が発生してしまったり。
画像を別のソフトで保存し直したりすると、正しく読めるようになることがあります。クラス側の問題っぽいのですが、謎……。
ふりがながついた
リンクポリシーでもって、「フレームの中に表示されるようなリンク」を禁止しているところが結構あります。それはある意味理解できるのですけれども、キッズ goo (kids.goo.ne.jp) のルビつき検索結果として意図せずにフレームの中に出ちゃったサイトからリンクしていたらどうなんでしょう。
……などというくだらないことを考えつつ、えび日記をキッズ goo で検索してふりがなつけてみました。
UTF-8 だからね……。
火の6月(リトライ)
リーヴェルファンタジア (www.amazon.co.jp)
どうでもいいですが、チャンドラーはあの状況からどうするつもりだったんでしょうか。「妖精の許し」を得て水晶を掘ったとして……その後、それを抱えて鉱山の入り口から普通に出るつもりだったのでしょうか。その場合、怒りに燃えた人々が出口を固めていそうな気がするんですが……。
ほとんどやけくその行動、だったのかな。
関連する話題: 出来事 / ゲーム / リーヴェルファンタジア
- 前(古い): 2003年6月のえび日記
- 次(新しい): 2003年8月のえび日記
