新生鳩丸掲示板♯

正直なところ、初めてPS3が欲しいと思った。アイレム的にPS3以外の選択肢はないだろうし。りゅうさんが買ったら遊びに行きますのでよろしく（謎）。

>>とは言っても、無条件にオススメしたりはしませんし、私も今のところ実践するつもりはないのですが。

>このやり方が、なぜオススメできない感じなのか、実践しない感じなのか、

>その理由が明らかになるといいと思います。

「無条件にオススメしたりはしない」と言っているのは、「変換処理が重くなるかもしれない」「実装が面倒かもしれない」「結果出力されるデータのサイズが大きくなる」といったデメリットがあるからです。そういったデメリットが気になる場合は採用したくないこともあるでしょう。

　また、これはまだ思考実験の段階なので、他にもデメリットがあるかもしれませんし、メリットも実は小さいのかもしれません。

　実践しないと言っているのは、単に私が基本的に「全部DOM」派だからです。DOM操作だけでXHTMLを作る場合、文字参照への変換は出力時に自動的に行われてしまいますので、このような処理を書く余地がありません。

>しっかり実例もあるようです。

>http://slashdot.jp/~alp/journal/454573

これですか。

http://www.massangeana.com/mas/charsets/cjk-c.htm

> 行の始めが "zW" (7A 57) で始まっていると, そこから行末までを GB だとみなします。実際には改行は無視されます。 GB の後の改行を無視されたくない場合は行末に "#" (23)をつけます。その他, GB 行の途中に 1文字だけ ASCII を使いたいときは, たとえば "?" (3F) なら " ?" (20 3F) のように頭にスペースをつければよいなど, いくつかの工夫があります。

かなり古いエンコーディングのようで、さすがにウェブブラウザは対応していないようですが、iconvがさりげなく対応しているようです。

＞とは言っても、無条件にオススメしたりはしませんし、私も今のところ実践するつもりはないのですが。

このやり方が、なぜオススメできない感じなのか、実践しない感じなのか、

その理由が明らかになるといいと思います。

仕様に基づいたことなのか、たまたま解決する他の問題を気にしなくなることがかえって将来のリスクにつながらないか、

とかそんな感じでしょうか。

> 注釈に「ASCII非互換でものすごく変な文字符号化方式があったりしたら分かりませんが……」とある通り、そのホワイトリストでは想定外の挙動が起こらないことが保障できていません。

しっかり実例もあるようです。

http://slashdot.jp/~alp/journal/454573

>そうするとホワイトリストの出番がなくなってしまいますので。:-)

確かに ... :-) もしかして、地雷を踏んでしまったかな!? m(_ _)m

> ところでqvalueを認識する実装がqvalueの大小を無視して採用順序を逆転させたらRFC違反になるでしょうか。

結局、エンティティの決定方法は「12 Content Negotiation」にも定義されていないので、どんな決定方法を取ってもRFCに則していないことにはならないと思います。たとえば「サーバのお薦め」みたいなサーバ都合の評価軸も持つアルゴリズムにしている場合、正当な理由でqvalueの大小が無視されるという状況を発生させることができそうな気がします。とはいえ「サーバのお薦め」ってなんだか分かりませんが、よりヒットしているキャッシュの方とか?

>>>> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、

> とか言ってた人【誰】につられたので【クマー】そっちに言ってあげてください【謎】。

それはqvalueのみを条件に使う場合というコンテキストでのみ成り立つ文なので、お察しください(謎)。

> それはりゅうさんが勝手に察しているだけです。受信側も同じように察すると保証できるでしょうか【謎】。できないはずです【謎】。なぜならMIMEタイプを決定するのはりゅうさん【誰】が作成したソフトウェアではないからです【謎】。したがって【謎】記述順に優先して採用されることを期待してMIMEタイプを書くということに意味はないということになります【謎】。

自明であるはずのAcceptフィールドの優先順位すら明確に察せない私は、まだまだ察しスキルが足りないということなのでしょう(謎)。

>別途定める決定方法の採用が可能であれば、RFCのあの部分の内容は、特定のタイプに対応するqvalueの決定方法というだけの事になるので、qvalueのみで採用するタイプを決定しなければならない訳ではないということになるかと思います。

qvalueは同じ値になることもあるのでqvalueのみで決定しなければならない訳ではないことは明らかだと思います。ところでqvalueを認識する実装がqvalueの大小を無視して採用順序を逆転させたらRFC違反になるでしょうか。

>ちなみにRFCから察する限り、優先順位は一次元配列内の位置として表されるので、同じ優先順位のものが存在することはないはずです。

それは

>>> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、

とか言ってた人【誰】につられたので【クマー】そっちに言ってあげてください【謎】。

>「Media ranges can be overridden by more specific media ranges or specific media types.」とあるので、詳細度によってオーバーライドされるべき元々の何かがあるはずです。オーバーライドされた結果起るのが優先順位の変化ということは、何らかの方法で元の優先順位が定義されるはずですが、恐るべきことにそれは明示されていません。それに使える情報は記述順くらいしか無いので、察する限りまあそういうことではないかと。

それはりゅうさんが勝手に察しているだけです。受信側も同じように察すると保証できるでしょうか【謎】。できないはずです【謎】。なぜならMIMEタイプを決定するのはりゅうさん【誰】が作成したソフトウェアではないからです【謎】。したがって【謎】記述順に優先して採用されることを期待してMIMEタイプを書くということに意味はないということになります【謎】。

仕様も変更されていて、現在の登録情報の確認・変更・配信停止のリンクには「act」「k」に加え「h」パラメータ（今度はハッシュですか）が追加され、何かをパラメータ化したみたいです。

登録変更などのリクエストをした時と同じブラウザからじゃないとアクセスできないようにしたってのがこれみたいです。まさかUser-Agentのハッシュなんてマヌケじゃないだろうとは思うけど、詳しく調べてないのでわかりません。あと、永久に有効だったのが期限付きになってます。うかつにも小刻みに調べなかったので実際のところは不明ですが、4日前のリンクはもう無効でした。

というわけで、システムの欠陥は認識してるようだけど、あくまで貼った奴が悪いと。

せっかくなので私も真剣に考えてみました。以下本文。

ホワイトリストによるフィルタリングというのは、ソフトウェアが扱う値を動作保障されている範囲に限定することによって、想定外の挙動が起こることを防ぐというものです。したがってホワイトリストに含まれるものは、なんらかの方法によって動作保障がなされているものである必要があります。そうでないものはすべて「グレー」で、ホワイトリストに含めるべきものではありません。

注釈に「ASCII非互換でものすごく変な文字符号化方式があったりしたら分かりませんが……」とある通り、そのホワイトリストでは想定外の挙動が起こらないことが保障できていません。したがって [0-9a-zA-Z] は「グレー」で、「白」ではない以上ホワイトリストに含めることは適切ではありません。ということでホワイトリストには何も含まれなくなり、すべての文字をエスケープすることになるわけですが、それで想定外の挙動は起こらないと保証できるでしょうか。できないはずです。なぜなら問題を起こすのは自分が作成したソフトウェアではないからです。

ウェブアプリケーションが出力したデータで問題を起こすのは、データを受け取った側のソフトウェアで、ほとんどの場合それは他人が作成したものです。他人が作成したソフトウェアの動作を保障することはできないため、出力のホワイトリストというものを作成するということができません。作ったとしてもそれは出力側が勝手に考えた「白」っぽいリストというだけであって、受け手側のホワイトリストである保障はありません。したがって出力をホワイトリストで処理するということに意味は無いということになります。

>あとで調べてみたら3年前ではなく2年以上前、三年未満でした(3年ほど前って書くつもりでした)。

>>Date: Thu, 9 Feb 2006 13:25:35 +0900

>>Subject: 【楽天市場からのお知らせ】メルマガ登録情報の確認・変更・配信停止について

　情報ありがとうございますー。

　まあ、いずれにしても事実上無期限ということですよね……。

>「なんでもエスケープしとけ、念のため」という考え方を突き詰めていくと「0-9A-Z」をなぜ文字実態参照しない?

>という事にはなりますね。

　そうですね。それらも文字参照にしてしまっても問題ないと思います。

　が、そうするとホワイトリストの出番がなくなってしまいますので。:-)

# 元々、「出力にホワイトリストっていうのはどういうことだろう?」というところからスタートした思考実験ですので、「ホワイトリストを使う」という前提で調整しています。

うわあ。私のコメントが引用されている^^;

あとで調べてみたら3年前ではなく2年以上前、三年未満でした(3年ほど前って書くつもりでした)。

>Date: Thu, 9 Feb 2006 13:25:35 +0900

>Subject: 【楽天市場からのお知らせ】メルマガ登録情報の確認・変更・配信停止について

これは金床さんの「ウェブアプリケーションセキュリティ」P72 の "過剰なエスケープ" というものですね。

話変わって、

「なんでもエスケープしとけ、念のため」という考え方を突き詰めていくと「0-9A-Z」をなぜ文字実態参照しない?

という事にはなりますね。

そもそも論として、

"[ホワイト|ブラック]リスト" という言葉を出力時に持ち込むのはどうか、と思いました。

タブーをなくすために議論する、という目的であれば、有効だとは思いますが。

> だから元記事では冗長だと言っているのでは? そうなるとRFCに「無意味」な例が載せられていることになるので妙と言えば妙ですが。

そこまでRFCを読み込んでいるなら曖昧なRFCの方を批判しそうな気がしますが、「悪いのはMS」脳になっているのかもしれません。

> 「*/*」だけが指定されたときとかそもそも指定されていないときとかも決定できないと困りますから、優先順位の同じものが並んでいたら別途定める決定方法を採用してもかまわないのだと思います。

別途定める決定方法の採用が可能であれば、RFCのあの部分の内容は、特定のタイプに対応するqvalueの決定方法というだけの事になるので、qvalueのみで採用するタイプを決定しなければならない訳ではないということになるかと思います。

ちなみにRFCから察する限り、優先順位は一次元配列内の位置として表されるので、同じ優先順位のものが存在することはないはずです。

> 詳細度やqvalueの高いMIMEタイプ指定を後に行うことも可能なので明らかに記述順は優先順位と異なるでしょう。RFCの例もそうなっています。

「Media ranges can be overridden by more specific media ranges or specific media types.」とあるので、詳細度によってオーバーライドされるべき元々の何かがあるはずです。オーバーライドされた結果起るのが優先順位の変化ということは、何らかの方法で元の優先順位が定義されるはずですが、恐るべきことにそれは明示されていません。それに使える情報は記述順くらいしか無いので、察する限りまあそういうことではないかと。

> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、優先順位も加味しないとうまく行かない感じがします。

だから元記事では冗長だと言っているのでは? そうなるとRFCに「無意味」な例が載せられていることになるので妙と言えば妙ですが。

> とはいえ最終的なメディアタイプの決定方法が仕様として明示されていないのであれですが。

「*/*」だけが指定されたときとかそもそも指定されていないときとかも決定できないと困りますから、優先順位の同じものが並んでいたら別途定める決定方法を採用してもかまわないのだと思います。

> そもそも記述順＝優先順位ということすら明示されていないような。

詳細度やqvalueの高いMIMEタイプ指定を後に行うことも可能なので明らかに記述順は優先順位と異なるでしょう。RFCの例もそうなっています。

>ただ、この直後に続く文章と併せて読むと、"precedence"はクライアントが好むMIMEタイプの優先順位ではなく、qvalue決定のためにリストを検索する順序の決定に用いられるものであるように読めるのが気になるのですが…。

最終的なメディアタイプの決定にqvalueだけを使用すると、意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、優先順位も加味しないとうまく行かない感じがします。とはいえ最終的なメディアタイプの決定方法が仕様として明示されていないのであれですが。そもそも記述順＝優先順位ということすら明示されていないような。

某大臣の舌禍事件といい、アメリカ大統領選といい、平壌放送といい、政治と扇動って切って切れない関係にあることを痛感しますね。