アカウント名:
パスワード:
そもそもWebにおけるセキュリティがかなり不確かな多数の仮定とバッドノウハウの上になんとか成り立っていて、こういった「想定外」の仕様変更に脆弱であるというのが今回の問題の本質でしょう。JPRSの考慮不足を責めるのは簡単だけど、そろそろWeb自体のセキュリティのフレームワークをどうにかするのが生産的だと思いますけどね。
検討の上で「どうせWebのセキュリティなんかgdgdなんだから地域型ドメインのCookie Monsterごとき誤差の範囲」とかほざいたんなら(当否はともかく)何らかの考えに基づいた主張であることは理解できなくもないが、そもそも検討した形跡が(少なくとも議事録からは)一切見当たらないんだから話にならない。
そうだよね、これ見方よっては、これはドメイン名空間の構造に独自の仮定を入れてcookiesの扱いを決めてるブラウザの不具合だよね。MozillaやGoogleに『おたくのブラウザ、DNS運用の実情と合わなくなったので実装変えたほうがいいっすよ』と言うならともかく、規格も法令を一切違反していない一レジストリを公開質問状まで出して非難するなんて、わけがわからないよ、というのがDNS屋の感想……なんだけど、Web屋からすればJPRSが十分な調査せずに勝手なことしたから現にセキュリティリスクと不具合が生じたじゃないか、なんだろうな。どっちの言い分もあると思う。
インターネットの精神（？）って、ルールがない（違反じゃない）なら、やっていい！ものではなく、他に迷惑かけるようなら一歩引く遠慮深さ、だと思う。SPAM だって、送りたいメールを送ってるだけです、て言われて御意、って納得する？
迷惑かけたって話なら、どっちもどっちじゃね？JPRSの考慮不足で不具合という側面もあれば、Webブラウザベンダがクッキーモンスターバグへのあまりにも適当な対策としてPublic Suffix Listというリストを（当初よりDNS屋から強い反対があったにもかかわらず）普及させてくれたせいでドメイン名空間に理不尽な制約を与えているという側面もある。高木先生はいつもの癖で特定の誰かを非難するんだけど（そのほうがウケるしね）、私はそうじゃないと思います。
> 当初よりDNS屋から強い反対があったにもかかわらず
そんな事実はないですね。嘘はいかん。
誰がDNS屋かというのはあるけど、Mozilla が IETF dnsop MLにPSLのアナウンスした時は非難轟々だった、って力武先生が言ってた。 [dnsops.jp]
オリジナルの英語ソースは？
http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html [ietf.org]
非難囂々かどうかは、自分で確認して元の人と戦ってくれオレは探すだけの係だから
横だけど、チラ見した感想・提案して2時間で「"手動集中管理"で"ハードコード"とか馬鹿なの死ぬの」と指摘されているにも関わらず強行し、案の定指摘された通りのことが起こっているわけでザマァ・この議論押し切ってmozillaが「ちゃんとやります」とほざいた以上、DNS屋はgTLD追加したら粛々とmozillaに通知すれば十二分以上の責任は果たしているわけで、そこからそれをどうやってブラウザにきちんと反映させるのかはWeb屋の責任。お前らが出来ると言ったからそういう仕様なんだぜ?だと思った。
Web屋はJPRSをdisる前に、場当たりでスケーラビリティのない馬鹿な仕様を盛り込んだブラウザを既に配っちゃって引き返せない状態にしちゃてごめんなさいって言うのが先。これが1978年だの1988年だのの話なら仕方ないにゃーで済むかもしれんが2008年に作った仕様とか同情の余地がねえよ。
で、JPRSはどんなリストをmozillaに通知するの？w
（はじめからそういう話だと気づけよw）
JPRSはmozillaにメールで一言「こんなsuffix作ったから後ヨロ」って言うだけだよ。これは簡単だしやるだろう。どんなリストってそのまんま新しく新設した都道府県別ドメインはこれですって渡すだけ。この先はmozillaがリストを作ってなんかしらんが頑張って世界中のブラウザに反映させる。分散型ではなく集中型の管理を主張し、俺がちゃんと管理しますとmozillaが押し切ったんだから、そういうルールになっているし筋論としてもそうなる。これに対して、高木氏はその更新と反映をどうやってやるのかと「JPRSに」質問状出してるわけだけど、それをJPRSに聞くのは筋違いじゃんって話。だってそんなのDNS屋の知ったことかよ。「おいおいこんな保守方法でメンテできるわけねーだろ」「mozillaが気合でやります」「ふーん、じゃあがんばってね」というやり取りは3年前に過ぎてる。ちゃんと配れないならごめんなさいするのはmozilla。その上で、Public Suffix Listの場当たり的なクソ仕様のせいで致命的に拡張性が失われてしまった問題に対して、諦めて「suffixはまともに増やせない」という現実をみんなで受け入れるのか、Public Suffix Listなんてまだ3年しかやってないんだから今なら捨てられると考えて今すぐ捨てて新しい仕様を作るのか、その辺は別の話だがとりあえず前者をチョイスして欲しいならまずPublic Suffix List支持派は土下座しろ。
論旨には同意するけど、いちおう補足。
>どんなリストってそのまんま新しく新設した都道府県別ドメインはこれですって渡すだけ。
これは違います。これまでの地域型 JP ドメインは chiyoda.tokyo.jp のような形式だったので、xxx.tokyo.jp なら public suffix だよ、というのがすでに47都道府県分入ってます。
都道府県 JP 導入後は、chiyoda.tokyo.jp は public だけど example.tokyo.jp は public じゃないよ、というのを区別する必要が出てきます。つまり、publix suffix list に追加する必要があるのは都道府県ドメイン47個ではなく、地域型で使われていた日本の全市区町村ドメイン数千個です。
高木氏が問題視してるのは追加すべき数があまりに多いことなんじゃないかと思いますが、まあ、そんなの知ったことじゃないですね。そんな仕様を作ってしまった方が悪い。
補足の補足。
"public suffix list" としては数千行増えることになりますが、"public suffix" として増えるのは47個だけです。これまでリスト1行で複数の市区町村をワイルドカード指定していたのが、ワイルドカードではなく明示的に1個ずつ指定しなければいけなくなったということ。
まあ現行の*.[県名].jpをpublic suffixであるとして扱うということ自体が既に無理矢理臭かったわけですし、初期から「管理単位とレベルの深さは一致してないよ。テーブル爆発すんじゃね」という指摘はされていたわけですから、自業自得としか言いようがないですねぇ。JPRSは粛々と数千行からなるsuffix listを送りつけてやればいいんじゃないでしょうか。それで「この仕様ダメだわ」と見直す契機になるなら良いことだと思います。
現行でもクッキー周りが変？な訳だよね。そもそも厳密な仕様があるのかすごい疑問なんだけど。
# クッキーモンスターバグは、バグの救済策が放置された結果だと思う
> これはドメイン名空間の構造に独自の仮定を入れてcookiesの扱いを決めてるブラウザの不具合だよね。
ブラウザじゃなくて、HTTPでは？
ドメイン名の構造に独自の仮定を入れて、といっても、今までのJPドメインの運用規定では通用したものだから、100%独自と言い切れないわけです。もちろん、今の規定が永遠に続くという保証はないのだけど、JPRSという公の組織が一旦は宣言したものだし、それを前提としたアプリや設定が存在してもおかしくないから、JPRSお前らそのリスクの検討は少しはしたのかという指摘は間違いではないと思いますね。
明確に不具合やセキュリティリスクだと言えるのはすでに広く指摘されている public suffix list による cookie monster問題だけど、それ以外の懸念
> 今までのJPドメインの運用規定では通用したものだから、100%独自と言い切れないわけです今回最大の問題になっているのは「JPドメインの運用規定が永久に変更されない」という「独自の仮定」なので、100%独自です。そもそも変更を動的に反映させるためにDNSというシステムがあるわけですから、「永久に続くという保証はない」どころではなく「動的にしょっちゅう変わることが大前提」です。汎用JPドメインの導入時に同じようなことを一度やっているんですよ。
今の運用ルールが続くことを前提としてはいけないというのは大前提ですので、それを決め打ったアプ
それだったら少なくともその「Web全体のセキュリティのフレームワーク」とやらができるまでは凍結すべきでしょう。そうじゃないから批判が上がっているわけで。
こういう事例をみるにつけ、どこかGlobalな場所にチェックリストなんか無いのかなと思ってしまう。識者を呼び入れても考慮漏れは発生し得るわけだし、でもそういうリストがあると識者はご飯の種が減っちゃうのかな。独自ではそういったリストを持っているのかも知れないが。
ま、あっても見ないけど。
どっちも詳細は分かってないけど、SPF 【Sender Policy Framework】のごとくDNSに実装してしまう方がましだったのかしら、とは思う。
当時からそうすべきという指摘はされていますね。mozillaが手作業で集中管理してブラウザにハードコードで埋め込んでバージョンアップ時に更新とか有りえんだろう、と。これに対してmozillaは「Firefoxはバージョンアップ早いから大丈夫」と押し切ってしまっています。あたまわるい
SPF方式にすると80番しか通さないProxyの裏にいるとフィールドが取得できない問題がありますが、SPF方式にしてProxy問題は別途救済方法を考えるとした方が事態は簡単だったでしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
JPRSの考慮不足を責めるのは簡単だけど (スコア:0)
そもそもWebにおけるセキュリティがかなり不確かな多数の仮定とバッドノウハウの上になんとか成り立っていて、こういった「想定外」の仕様変更に脆弱であるというのが今回の問題の本質でしょう。JPRSの考慮不足を責めるのは簡単だけど、そろそろWeb自体のセキュリティのフレームワークをどうにかするのが生産的だと思いますけどね。
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:2, すばらしい洞察)
検討の上で「どうせWebのセキュリティなんかgdgdなんだから地域型ドメインのCookie Monsterごとき誤差の範囲」とかほざいたんなら(当否はともかく)何らかの考えに基づいた主張であることは理解できなくもないが、そもそも検討した形跡が(少なくとも議事録からは)一切見当たらないんだから話にならない。
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:2, 興味深い)
そうだよね、これ見方よっては、これはドメイン名空間の構造に独自の仮定を入れてcookiesの扱いを決めてるブラウザの不具合だよね。MozillaやGoogleに『おたくのブラウザ、DNS運用の実情と合わなくなったので実装変えたほうがいいっすよ』と言うならともかく、規格も法令を一切違反していない一レジストリを公開質問状まで出して非難するなんて、わけがわからないよ、というのがDNS屋の感想……なんだけど、Web屋からすればJPRSが十分な調査せずに勝手なことしたから現にセキュリティリスクと不具合が生じたじゃないか、なんだろうな。どっちの言い分もあると思う。
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:1)
インターネットの精神（？）って、ルールがない（違反じゃない）なら、やっていい！
ものではなく、他に迷惑かけるようなら一歩引く遠慮深さ、だと思う。
SPAM だって、送りたいメールを送ってるだけです、て言われて御意、って納得する？
Re: (スコア:0)
迷惑かけたって話なら、どっちもどっちじゃね？
JPRSの考慮不足で不具合という側面もあれば、Webブラウザベンダがクッキーモンスターバグへのあまりにも適当な対策としてPublic Suffix Listというリストを（当初よりDNS屋から強い反対があったにもかかわらず）普及させてくれたせいでドメイン名空間に理不尽な制約を与えているという側面もある。
高木先生はいつもの癖で特定の誰かを非難するんだけど（そのほうがウケるしね）、私はそうじゃないと思います。
Re: (スコア:0)
> 当初よりDNS屋から強い反対があったにもかかわらず
そんな事実はないですね。嘘はいかん。
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:1)
誰がDNS屋かというのはあるけど、Mozilla が IETF dnsop MLにPSLのアナウンスした時は非難轟々だった、って力武先生が言ってた。 [dnsops.jp]
Re: (スコア:0)
オリジナルの英語ソースは？
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:1)
http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html [ietf.org]
非難囂々かどうかは、自分で確認して元の人と戦ってくれ
オレは探すだけの係だから
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:1)
横だけど、チラ見した感想
・提案して2時間で「"手動集中管理"で"ハードコード"とか馬鹿なの死ぬの」と指摘されているにも関わらず強行し、案の定指摘された通りのことが起こっているわけでザマァ
・この議論押し切ってmozillaが「ちゃんとやります」とほざいた以上、DNS屋はgTLD追加したら粛々とmozillaに通知すれば十二分以上の責任は果たしているわけで、そこからそれをどうやってブラウザにきちんと反映させるのかはWeb屋の責任。お前らが出来ると言ったからそういう仕様なんだぜ?
だと思った。
Web屋はJPRSをdisる前に、場当たりでスケーラビリティのない馬鹿な仕様を盛り込んだブラウザを既に配っちゃって引き返せない状態にしちゃてごめんなさいって言うのが先。
これが1978年だの1988年だのの話なら仕方ないにゃーで済むかもしれんが2008年に作った仕様とか同情の余地がねえよ。
Re: (スコア:0)
で、JPRSはどんなリストをmozillaに通知するの？w
（はじめからそういう話だと気づけよw）
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:1)
JPRSはmozillaにメールで一言「こんなsuffix作ったから後ヨロ」って言うだけだよ。これは簡単だしやるだろう。どんなリストってそのまんま新しく新設した都道府県別ドメインはこれですって渡すだけ。
この先はmozillaがリストを作ってなんかしらんが頑張って世界中のブラウザに反映させる。分散型ではなく集中型の管理を主張し、俺がちゃんと管理しますとmozillaが押し切ったんだから、そういうルールになっているし筋論としてもそうなる。
これに対して、高木氏はその更新と反映をどうやってやるのかと「JPRSに」質問状出してるわけだけど、それをJPRSに聞くのは筋違いじゃんって話。だってそんなのDNS屋の知ったことかよ。「おいおいこんな保守方法でメンテできるわけねーだろ」「mozillaが気合でやります」「ふーん、じゃあがんばってね」というやり取りは3年前に過ぎてる。ちゃんと配れないならごめんなさいするのはmozilla。
その上で、Public Suffix Listの場当たり的なクソ仕様のせいで致命的に拡張性が失われてしまった問題に対して、諦めて「suffixはまともに増やせない」という現実をみんなで受け入れるのか、Public Suffix Listなんてまだ3年しかやってないんだから今なら捨てられると考えて今すぐ捨てて新しい仕様を作るのか、その辺は別の話だがとりあえず前者をチョイスして欲しいならまずPublic Suffix List支持派は土下座しろ。
Re: (スコア:0)
論旨には同意するけど、いちおう補足。
>どんなリストってそのまんま新しく新設した都道府県別ドメインはこれですって渡すだけ。
これは違います。これまでの地域型 JP ドメインは chiyoda.tokyo.jp のような
形式だったので、xxx.tokyo.jp なら public suffix だよ、というのがすでに
47都道府県分入ってます。
都道府県 JP 導入後は、chiyoda.tokyo.jp は public だけど example.tokyo.jp は public じゃないよ、
というのを区別する必要が出てきます。
つまり、publix suffix list に追加する必要があるのは都道府県ドメイン47個ではなく、
地域型で使われていた日本の全市区町村ドメイン数千個です。
高木氏が問題視してるのは追加すべき数があまりに多いことなんじゃないかと思いますが、
まあ、そんなの知ったことじゃないですね。そんな仕様を作ってしまった方が悪い。
Re: (スコア:0)
補足の補足。
"public suffix list" としては数千行増えることになりますが、
"public suffix" として増えるのは47個だけです。
これまでリスト1行で複数の市区町村をワイルドカード指定していたのが、
ワイルドカードではなく明示的に1個ずつ指定しなければいけなくなったということ。
Re: (スコア:0)
まあ現行の*.[県名].jpをpublic suffixであるとして扱うということ自体が既に無理矢理臭かったわけですし、
初期から「管理単位とレベルの深さは一致してないよ。テーブル爆発すんじゃね」という指摘はされていたわけですから、
自業自得としか言いようがないですねぇ。
JPRSは粛々と数千行からなるsuffix listを送りつけてやればいいんじゃないでしょうか。
それで「この仕様ダメだわ」と見直す契機になるなら良いことだと思います。
Re: (スコア:0)
現行でもクッキー周りが変？な訳だよね。
そもそも厳密な仕様があるのかすごい疑問なんだけど。
# クッキーモンスターバグは、バグの救済策が放置された結果だと思う
Re: (スコア:0)
> これはドメイン名空間の構造に独自の仮定を入れてcookiesの扱いを決めてるブラウザの不具合だよね。
ブラウザじゃなくて、HTTPでは？
Re: (スコア:0)
ドメイン名の構造に独自の仮定を入れて、といっても、今までのJPドメインの運用規定では通用したものだから、100%独自と言い切れないわけです。もちろん、今の規定が永遠に続くという保証はないのだけど、JPRSという公の組織が一旦は宣言したものだし、それを前提としたアプリや設定が存在してもおかしくないから、JPRSお前らそのリスクの検討は少しはしたのかという指摘は間違いではないと思いますね。
明確に不具合やセキュリティリスクだと言えるのはすでに広く指摘されている public suffix list による cookie monster問題だけど、それ以外の懸念
Re: (スコア:0)
> 今までのJPドメインの運用規定では通用したものだから、100%独自と言い切れないわけです
今回最大の問題になっているのは「JPドメインの運用規定が永久に変更されない」という「独自の仮定」なので、100%独自です。
そもそも変更を動的に反映させるためにDNSというシステムがあるわけですから、「永久に続くという保証はない」どころではなく「動的にしょっちゅう変わることが大前提」です。
汎用JPドメインの導入時に同じようなことを一度やっているんですよ。
今の運用ルールが続くことを前提としてはいけないというのは大前提ですので、それを決め打ったアプ
Re: (スコア:0)
それだったら少なくともその「Web全体のセキュリティのフレームワーク」とやらができるまでは凍結すべきでしょう。
そうじゃないから批判が上がっているわけで。
Re: (スコア:0)
こういう事例をみるにつけ、どこかGlobalな場所にチェックリストなんか無いのかなと思ってしまう。
識者を呼び入れても考慮漏れは発生し得るわけだし、でもそういうリストがあると識者はご飯の種が減っちゃうのかな。
独自ではそういったリストを持っているのかも知れないが。
ま、あっても見ないけど。
Re:JPRSの考慮不足を責めるのは簡単だけど (スコア:2)
どっちも詳細は分かってないけど、SPF 【Sender Policy Framework】のごとくDNSに実装してしまう方がましだったのかしら、とは思う。
Re: (スコア:0)
当時からそうすべきという指摘はされていますね。
mozillaが手作業で集中管理してブラウザにハードコードで埋め込んでバージョンアップ時に更新とか有りえんだろう、と。
これに対してmozillaは「Firefoxはバージョンアップ早いから大丈夫」と押し切ってしまっています。
あたまわるいSPF方式にすると80番しか通さないProxyの裏にいるとフィールドが取得できない問題がありますが、SPF方式にしてProxy問題は別途救済方法を考えるとした方が事態は簡単だったでしょうね。