アカウント名:
パスワード:
擬似ウィンドウは、少なくともInternet Explorer 7とOpera 9.62とSafari 3.2.1とGoogle ChromeではGadgetです。FirefoxだけがまだiframeをWidgetで実装していますが、 Gadget化する計画 [mozilla.org]があります。WidgetとGadgetが混じるとCSSの仕様に忠実なZ orderの処理などで破綻することが多いので、どのブラウザもどんどんGadget化を進めています。
さらに言えば、その矩形領域を「透明」にしておいて、なおかつ入力領域に対するキー入力等だけは拾う…なんて事も自在なわけだ。
こういうことはDOMイベントを監視することでGadgetベースでも問題なく可能なので、なんでWidget対Gadgetという話になるのかよくわかりません。
ちなみに歴史的経緯からプラグ
(ある人が信用しているWebサイトが、危険な「ページ内JavaScriptウィンドウ」を表示させることがあるかもしれないが、それが悪意あるサイトならば信用するのが誤りであるし、悪意あるサイトでないならば、それはそのWebサイトのセキュリティ脆弱性であって、修正されるべきものである。修正されないようなサイトならば、信用するのが誤りということになる。で十分答えになっている気がするのですが。
(ある人が信用しているWebサイトが、危険な「ページ内JavaScriptウィンドウ」を表示させることがあるかもしれないが、それが悪意あるサイトならば信用するのが誤りであるし、悪意あるサイトでないならば、それはそのWebサイトのセキュリティ脆弱性であって、修正されるべきものである。修正されないようなサイトならば、信用するのが誤りということになる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
いいえ、<del>ケフィア</del>Gadgetです (スコア:1)
擬似ウィンドウは、少なくともInternet Explorer 7とOpera 9.62とSafari 3.2.1とGoogle ChromeではGadgetです。FirefoxだけがまだiframeをWidgetで実装していますが、 Gadget化する計画 [mozilla.org]があります。WidgetとGadgetが混じるとCSSの仕様に忠実なZ orderの処理などで破綻することが多いので、どのブラウザもどんどんGadget化を進めています。
こういうことはDOMイベントを監視することでGadgetベースでも問題なく可能なので、なんでWidget対Gadgetという話になるのかよくわかりません。
ちなみに歴史的経緯からプラグ
Re:いいえ、ケフィアGadgetです (スコア:1)
それは「実装にX11のWidgetを使うかGadgetを使うか」という話と「Widget/Gadgetとはそもそも何か」の違いを理解してらっしゃらないのではないかと。
X11のWidget/Gadget問題に関しては、おっしゃるとおり。独立したレンダラを必要とするhtmlブラウザの世界では、わざわざX11のWidgetを使わなくてもGadgetで十分ですし、Gadgetの方が厳密に描画ルールを制御できますし、動作性能も保証できます。そもそも「最終イメージにいたるレンダリング処理の、どこまでを、どこでやればいいのか」と言うのはXに限らずグラフィックの世界では常に問題になります。
しかし、X11においても「同じXserver」が異なるクライアントから来たWidgetを描画する事ができるように、単一のレンダラが2つ以上の情報源から来た描画オブジェクトを1つの描画プレーンに描くことが出来ます。これもWidgetです。HTMLレンダラがそれを単一Widget上に描画してX11(やMS-Windows)に描画せよ、と言っていたとしても、HTMLレンダラのレベルではWidgetです。「Geckoレベルで2つのWidgetがあり、それをGeckoはレンダリングして単一GadgetとしてX11に描画させている」という状態に過ぎません。
そして今回セキュリティ上の問題をもたらしているのはHTMLレンダラから見てのWidgetです。X11レベルでのWidget/Gadgetではありません。
.
ここでいう「描画する」の中には「透明なデータを描画する」事が含まれます。透明なデータというのはいくとおりも実装方法がありますが、ようするに最終病が結果としてそのオブジェクトが存在するのかしないのか、区別する方法が無ければよい。必ずしも「何も描画しない」ばかりが「透明」ではありません。
なりません。全くもってなりません。
上記の記述は「ページ内Javascriptウィンドウを表示させる」かどうかを、ブラウザが表示する内容から推定できる、と言う前提があります。しかし「透明なデータを描画できる」と言うことは「あるオブジェクトが描画されているのかいないのか、見てくれから知る術は無い」と言うことです。と言うことは全てのWebサイトは信頼ならないと言っているだけです(もちろん、「自分で作ったページは別にして」という意味ですが)。これはWebなんて信頼ならぬと言っているだけです。信頼できるかどうかを評価するためには毎回ソースを精査する必要があるのですから。
.
この問題はX11の時にもあった問題です。X11も初期の段階では「Xserverは全てのマシンからの描画リクエストを受け付ける」状態になっていました。このため、透明なWidgetを作り上げてイベントを全て横取りする事が可能でした。XのときはXserver側でアクセス制限を設定する事でこの問題に対処しました。信頼できるサーバをXserverの利用者が定義していたわけです。Xの場合はこれも可能でした。
しかし、Webはそもそも html などのソースをあちらこちらから取ってきて、それを手元で描画する事に意味があります。レンダラレベルでは描画データの送り元は多岐に渡らなくてはいけない、X11のときのようにアクセス制御をかければオッケー、とはいかないと言うことです。
.
もちろん、透明なWidget以外にも擬態の方法はさまざまあります。ポップアップウィンドウに擬態する擬似ウィンドウ。レンダラの画面全体を覆いつくして「クラシックな見てくれ」を演出する擬似ウィンドウ。
これらの擬態は一旦始まったら最後、いつ終了しているのか知る術がありません。乱暴な話、
「ログインとか全く関係ないページで、ファンキーな画面を楽しんだら、実はそこで擬態ウィンドウを仕掛けられた。
その後ではてなに移動したら、ログイン情報を全部盗まれた。
はてなが独自の擬似ウィンドウを開く仕様になっていたら、別の擬似ウィンドウからは手の出しようがなかったのに、クラシックな画面デザインだったためにキーストロークイベントを盗まれたのが悪い」
なんて事だってありえるわけです。信頼できないサイトにアクセスしたら最後、一旦ブラウザを止めない限り、ブラウザ自体が信頼できる状態に戻らない。これはレンダラレベルで複数のWidgetを描画する状態に陥っているからです。
.
この問題は Javascriptが高機能化した瞬間に発生しているんです。HTMLレンダラが複数Widgetを描画するようになったのはJavascriptの高機能化に対応するために過ぎません。故に手遅れなんです。
fjの教祖様
Re: (スコア:0)
ブラウザ側が特定の領域を監視して、その上にあるJavaScriptのWidget/Gadgetにマウスカーソルが入ったら、
当該Widget/Gadgetの枠線を表示するというのはいかがでしょうか。
加えて、枠線の右上隅に耳をつけて、耳にカーソルを当てると当該Widget/Gadgetの情報をポップアップするようにすれば、
さらに判断がしやすくなるかと思います。
Re:いいえ、ケフィアGadgetです (スコア:1)
逆に入力領域ぴったりに作られると「今どこにフォーカスが当っているのか判りやすくしているんだ」としか判断されないかもしれません。Google Chrome の input 領域って、今フォーカスがあたっている部分だけふちの色が違いますよね? こういう機能との区別がつかない可能性がある。
それでも適用したとしても「色盲対策」なども含まねばなりません。赤と緑が区別できない人に「ふちが赤と緑で点滅している」などというインターフェースを与えてもうれしくないわけです。
.
高木先生が問題にしている問題の本質は
「信頼できないページから、信頼したいページへジャンプしたときに、
信頼できないページの『信頼できなさ』ぶりが『信頼したいページ』にまで波及するのをどう防ぐか」
というこの一点に尽きます。
この問題をUI側で解決するのはとても難しいんです。アドレスを表示させる等の機能はそりゃいくらでも実装できますが、
「ユーザがそれをチェックしてくれなくなるぐらいアドレスを山のように表示」
させられたら、結局ノーチェックと同じ状態に陥ります。そして、悪さをしたい側はそういう「物量作戦」と「目の錯覚」を利用して、ユーザを騙しにかかるでしょう。
可能なのは『信頼できるポイント』から手繰っていくデータが全て信頼できるよう、必要な URL を徹底的に ssl 化するしかないと思います。<script src="http://xxxxx" などという記述は論外という事ですが… /.Jも含めてほとんどのサイトは http ですよね。こういうのを直すほうがUIを直すよりも何億倍も重要です。
逆にそれらが信頼できるなら、擬似ウィンドウを使うUIでも問題ないと思うんですよ。もちろん、チェックできないという弱点はあるのですが「そもそも信頼できるという前提が立つならチェックする必要は無いだろう」と。
fjの教祖様