アカウント名:
パスワード:
ด้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้ (・ω・) ด็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็. ← Unicode 合字 の例 (IE で表示すると、本来のコメント欄の領域を多少はみ出して他の情報に重なります)
Unicode は複雑化されすぎて、普通のプログラマーが理解できる範疇を超えているように思えます。多言語に対応させる場合 Unicode を採用せざるを得ないのですから、絵文字といった余計な拡張を加えて更に複雑化させないでほしいです。合字についても、Unicode の仕様において、ありとあらゆる方向に無限に伸ばせるような仕様にせずに、個数などを限定すれば良かったのではないでしょうか。
私の場合、Unicode について勉強してみたところ、適切に validation するのは極めて難しいことが分かったので、UTF-8 といったUnicode文字集合の符号化方式 を使うのは諦め、EUC-JP を主に使っています。勿論、その場合には多言語化は諦めなくてはなりません。
Webアプリケーションで、UTF-8 などの文字コードを用いた場合、Unicode の合字や制御コードを適切に validation しないと、ページのほぼ全体を変な記号文字で上書きされてまともに表示できなくする、アクセスしただけでブラウザがフリーズする状態にするといったサービス拒否攻撃の被害に遭う恐れがあります。しかしながら、PHP などのWebアプリケーション開発言語において、PHP の制御コード等を適切に validation する関数は用意されていません。
勿論、これはユーザーから入力されたUnicode文字を第三者に出力する全てのネットサービスに言えることで、LINE ではUnicodeの制御文字によってLINEアプリがフリーズしたり起動できなくなったりする所謂「LINEウイルス」 [did2memo.net]の被害が多発しています。また、Windowsの世界でも同様でUnicodeの不正な制御文字を投稿されることによって、Skype・ニコニコ動画・アメーバピグでエラーが発生するといった被害があり、UnicodeCrashGuard [hange.info] といった対策ソフトまで使われている始末です。
ちなみに、このコメント最上部の例は、タイ文字の上に結合用の声調符号を付けたものです。本来、タイ語の声調符号はタイ語の言語文法上複数個付くものではありませんが、Unicode ではそれが許されるので、無限に伸ばして上下のスペースを占有することができてしまうのです(IEで表示する場合)。
Unicode の多言語の問題と絵文字の問題は分けましょうか。
Unicode 以前から、多言語対応を適切に扱えるプロダクトが一握りしかなかったことを考えると普通のプログラマが Unicode のすべてを適切に扱えないのはある意味仕方がないかと。適切なサイズの文字集合を使うのは現実的な手ですね。iso-2022-* ではなくて、iso-2022-jp のみ対応みたいな。
Unicode の厄介なところはサブセット化が困難なところです。つまり、多言語対応 = 全言語対応にするしかない。文字コードから使用されている言語が判断できればまだ違ったのですが。
また、合字について個数を限定すればという意見もありますが規格で定めてしまうと、規定個数を超えた文字列は Unicode を満たさないということになりますね。ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。これは実装コストが高いと思います。
規格を拡張するなというのは無理ですね。現実に使われている / 問題があるのに対応しないなんて、規格の存在意義がないでしょう。
絵文字はすでに広く使われています。カラーフォント化に伴い起きつつある政治的な問題の火種を、技術的にどう解決するべきかが議論の中心ですので規格を複雑化させないために対応しないという回答はありえません。
確かにその方が良いですね。
絵文字はすでに広く使われています。 カラーフォント化に伴い起きつつある政治的な問題の火種を、技術的にどう解決するべきかが議論の中心ですので 規格を複雑化させないために対応しないという回答はありえません。
アメリカには言いがかりをつけるのが仕事の人権団体の方が多数いらっしゃいますから、Unicode 拡張で技術的に対応していたらきりがありません。肌の色に対応したら、今度は目の色だとか、髪の色に文句を付けてくるでしょうし、顔の形も変えられるようにしろと言ってくるでしょう。
そうなると、Nintendo の Mii のようにしなければならず、パラメーターがたくさん必要になります。
したがって、Unicode での絵文字の取り扱いをやめて、絵文字は画像にした方が良い [srad.jp] と思います。
おっしゃる通り、たくさんの労力が必要になり万人が納得する結果にはならないでしょう。それでも、いまさら絵文字の取り扱いをやめることはできませんし、問題を無かったことにすることもできません。できるのは現実的な折衷案に落とし込むことだけです。
専門家の言を借りると、
絵文字でパンドラの箱を空けてしまったのだから、コストはみんなで負担するしかない。 [impress.co.jp]
なのです。
開いた人が負担したらいいんじゃないかな・・開かない人用にサブセットが欲しい。
>ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。
1文字分のデータを受け取りきる前に1文字の正当性を保証なんてハナから無理じゃないの?…と思ったけど「1文書内での個数を限定」と読んだんですね。多分元コメは「1合字に付加できる個数を限定」という意味だと思いますよ。
いや、そんなに面白い読み方をする人は居ないでしょう。
正当性の検証の単位となる「1文字」が現状では非常に短い数バイトに限定されているから、バッファリングが必要な最大文字数もそれで十分だけど、「合字はn個まで可」とすると、さらにn×数バイトが追加で必要になって大変だ、とかそういう話では?
実際に必要なnは、高々2とか3なのかもしれませんが、それでも増やしてくれるなと。
>普通のプログラマーが理解できる範疇を超えているように思えます。
普通のプログラマーが変換以外でコード体系を意識しなきゃいけないことって、現代ではそうそう無くね? 文字が表示できず画面が崩れるのはOSや処理系の問題であって、プログラマーがいちいち意識しなければいけないというのはおかしいでしょう。
確かにおっしゃる通り、文字エンコーディングの validation をしなくても脆弱性にならないのが本来の姿ですが、現状はそうではありません。文字コードの脆弱性はこの3年間でどの程度対策されたか? [slideshare.net] をお読みいただければ分かるように、昔に比べるとプラットフォーム側での整備が進み安全性が強化されつつありますが、完璧とは言えない現状があります。
所謂マルチバイトXSSに対してはプラットフォーム側での対策がだいぶ進みましたが、Unicode の特殊文字や制御コードによるサービス拒否攻撃防止のための対策は全く進んでいません。特定のUnicode特殊文字・制御文字を送ると受信した側のLINEがフリーズ・起動不能になる現象については、そもそも iOS の Unicode の実装に問題があることが根本的な問題(Android については特殊な文字はそもそも対応していないので問題は発生していない)です。しかし、Apple は iOS の既存の Unicode の問題の修正もまともにせず、更に Unicode を複雑化させ問題を深刻化させたいようですから、アプリ側での validation を強化するしかないのではないでしょうか。
具体的には、ユーザーから送信されるデータを受け付ける際に、コード順ブロック一覧 [wikipedia.org] の中の特定の範囲のコードのみを受け付けて他はエラーにするなど。
--
別コメントにするほどではないので、ここについでに書いてしまいますが、 #2767675 の 「PHP の制御コード等を適切に validation」 は 「Unicode の制御コード等を適切に validation」 の誤りでした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
Unicode はサービス拒否攻撃のリスク有り (スコア:3, 興味深い)
ด้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้ (・ω・) ด็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็. ← Unicode 合字 の例 (IE で表示すると、本来のコメント欄の領域を多少はみ出して他の情報に重なります)
Unicode は複雑化されすぎて、普通のプログラマーが理解できる範疇を超えているように思えます。多言語に対応させる場合 Unicode を採用せざるを得ないのですから、絵文字といった余計な拡張を加えて更に複雑化させないでほしいです。合字についても、Unicode の仕様において、ありとあらゆる方向に無限に伸ばせるような仕様にせずに、個数などを限定すれば良かったのではないでしょうか。
私の場合、Unicode について勉強してみたところ、適切に validation するのは極めて難しいことが分かったので、UTF-8 といったUnicode文字集合の符号化方式 を使うのは諦め、EUC-JP を主に使っています。勿論、その場合には多言語化は諦めなくてはなりません。
Webアプリケーションで、UTF-8 などの文字コードを用いた場合、Unicode の合字や制御コードを適切に validation しないと、ページのほぼ全体を変な記号文字で上書きされてまともに表示できなくする、アクセスしただけでブラウザがフリーズする状態にするといったサービス拒否攻撃の被害に遭う恐れがあります。しかしながら、PHP などのWebアプリケーション開発言語において、PHP の制御コード等を適切に validation する関数は用意されていません。
勿論、これはユーザーから入力されたUnicode文字を第三者に出力する全てのネットサービスに言えることで、LINE ではUnicodeの制御文字によってLINEアプリがフリーズしたり起動できなくなったりする所謂「LINEウイルス」 [did2memo.net]の被害が多発しています。また、Windowsの世界でも同様でUnicodeの不正な制御文字を投稿されることによって、Skype・ニコニコ動画・アメーバピグでエラーが発生するといった被害があり、UnicodeCrashGuard [hange.info] といった対策ソフトまで使われている始末です。
ちなみに、このコメント最上部の例は、タイ文字の上に結合用の声調符号を付けたものです。本来、タイ語の声調符号はタイ語の言語文法上複数個付くものではありませんが、Unicode ではそれが許されるので、無限に伸ばして上下のスペースを占有することができてしまうのです(IEで表示する場合)。
Re:Unicode はサービス拒否攻撃のリスク有り (スコア:2)
Unicode の多言語の問題と絵文字の問題は分けましょうか。
Unicode 以前から、多言語対応を適切に扱えるプロダクトが一握りしかなかったことを考えると
普通のプログラマが Unicode のすべてを適切に扱えないのはある意味仕方がないかと。
適切なサイズの文字集合を使うのは現実的な手ですね。
iso-2022-* ではなくて、iso-2022-jp のみ対応みたいな。
Unicode の厄介なところはサブセット化が困難なところです。
つまり、多言語対応 = 全言語対応にするしかない。
文字コードから使用されている言語が判断できればまだ違ったのですが。
また、合字について個数を限定すればという意見もありますが
規格で定めてしまうと、規定個数を超えた文字列は Unicode を満たさないということになりますね。
ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。これは実装コストが高いと思います。
規格を拡張するなというのは無理ですね。
現実に使われている / 問題があるのに対応しないなんて、規格の存在意義がないでしょう。
絵文字はすでに広く使われています。
カラーフォント化に伴い起きつつある政治的な問題の火種を、技術的にどう解決するべきかが議論の中心ですので
規格を複雑化させないために対応しないという回答はありえません。
対応していたら際限が無い (スコア:2)
確かにその方が良いですね。
アメリカには言いがかりをつけるのが仕事の人権団体の方が多数いらっしゃいますから、Unicode 拡張で技術的に対応していたらきりがありません。肌の色に対応したら、今度は目の色だとか、髪の色に文句を付けてくるでしょうし、顔の形も変えられるようにしろと言ってくるでしょう。
そうなると、Nintendo の Mii のようにしなければならず、パラメーターがたくさん必要になります。
したがって、Unicode での絵文字の取り扱いをやめて、絵文字は画像にした方が良い [srad.jp] と思います。
Re:対応していたら際限が無い (スコア:1)
おっしゃる通り、たくさんの労力が必要になり万人が納得する結果にはならないでしょう。
それでも、いまさら絵文字の取り扱いをやめることはできませんし、問題を無かったことにすることもできません。
できるのは現実的な折衷案に落とし込むことだけです。
専門家の言を借りると、
なのです。
Re: (スコア:0)
開いた人が負担したらいいんじゃないかな・・
開かない人用にサブセットが欲しい。
Re: (スコア:0)
>ストリームに合字が現れたら常に先読みしなければ文字列の正当性を保証できない。
1文字分のデータを受け取りきる前に1文字の正当性を保証なんてハナから無理じゃないの?
…と思ったけど「1文書内での個数を限定」と読んだんですね。
多分元コメは「1合字に付加できる個数を限定」という意味だと思いますよ。
Re: (スコア:0)
いや、そんなに面白い読み方をする人は居ないでしょう。
正当性の検証の単位となる「1文字」が現状では非常に短い数バイトに限定されているから、
バッファリングが必要な最大文字数もそれで十分だけど、
「合字はn個まで可」とすると、さらにn×数バイトが追加で必要になって大変だ、とかそういう話では?
実際に必要なnは、高々2とか3なのかもしれませんが、それでも増やしてくれるなと。
Re:Unicode はサービス拒否攻撃のリスク有り (スコア:1)
Re: (スコア:0)
>普通のプログラマーが理解できる範疇を超えているように思えます。
普通のプログラマーが変換以外でコード体系を意識しなきゃいけないことって、現代ではそうそう無くね? 文字が表示できず画面が崩れるのはOSや処理系の問題であって、プログラマーがいちいち意識しなければいけないというのはおかしいでしょう。
Re:Unicode はサービス拒否攻撃のリスク有り (スコア:2)
確かにおっしゃる通り、文字エンコーディングの validation をしなくても脆弱性にならないのが本来の姿ですが、現状はそうではありません。文字コードの脆弱性はこの3年間でどの程度対策されたか? [slideshare.net] をお読みいただければ分かるように、昔に比べるとプラットフォーム側での整備が進み安全性が強化されつつありますが、完璧とは言えない現状があります。
所謂マルチバイトXSSに対してはプラットフォーム側での対策がだいぶ進みましたが、Unicode の特殊文字や制御コードによるサービス拒否攻撃防止のための対策は全く進んでいません。特定のUnicode特殊文字・制御文字を送ると受信した側のLINEがフリーズ・起動不能になる現象については、そもそも iOS の Unicode の実装に問題があることが根本的な問題(Android については特殊な文字はそもそも対応していないので問題は発生していない)です。しかし、Apple は iOS の既存の Unicode の問題の修正もまともにせず、更に Unicode を複雑化させ問題を深刻化させたいようですから、アプリ側での validation を強化するしかないのではないでしょうか。
具体的には、ユーザーから送信されるデータを受け付ける際に、コード順ブロック一覧 [wikipedia.org] の中の特定の範囲のコードのみを受け付けて他はエラーにするなど。
--
別コメントにするほどではないので、ここについでに書いてしまいますが、 #2767675 の 「PHP の制御コード等を適切に validation」 は 「Unicode の制御コード等を適切に validation」 の誤りでした。