「Webブラウザにダイアログ“詐称の脆弱性あり”との主張」記事へのコメント

ソフト固有の脆弱性というよりも

[Anonymous Coward]

ブラウザの基本仕様というか何年も続いてきた「常識的な設計」とか
既存概念とかそういったものからくる脆弱性ですね。
そもそも脆弱性と言っていいものかも難しいと思いますが…。

少なくともソフトウェア固有の問題ではないとおもいます。

GUIがまだ足らない。

[Anonymous Coward]

各種jsダイアログボックスが、どのウィンドウ及びサイトから発行された物かを視認しやすいGUIという物は、あまり考えられてこなかったですね。

金持ってる所のUIデザイナーが出してくれるマシなアイデアに期待します。

Mac OS X のシート

[targz (14071)]

＞各種jsダイアログボックスが、どのウィンドウ及びサイトから発行された物かを視認しやすいGUIという物は

Mac OS X から導入された「シート」は、最適ではないでしょうか?
ウィンドウのタイトルバー付近から垂幕のごとくダイアログが降りてくるというインターフェースです。ウィンドウとダイアログがくっついているので、両者が関係あるのが一目瞭然です。

ただ、このインターフェースが、Mac OS X における独自のものだと Apple が主張すると、他の OS で導入しにくくなりますね……。

Re:Mac OS X のシート

[NAT33 (17123)]

Fedora CoreでFirefox使っているが、件のデモだと、そのシートとやらと、ダイアログは同じような挙動してるんですが?

ダイアログの度に空白のウィンドゥがアクティブになるのは、疑ってくれと宣言しているようなものだと思う。

アクティブにならずに表の本物のウィンドゥにダイアログが出せるんなら、だまされる人も出そうだけど。

Re:Mac OS X のシート

[targz (14071)]

＞Fedora CoreでFirefox使っているが、件のデモだと、そのシートとやらと、ダイアログは同じような挙動してるんですが?

Mac 版の FireFox でもデモを試してみましたが、 JavaScript ダイアログがシートで表示されました。小さい空白ウィンドウからダイアログがにゅるっと出てきました。

Linux 版の FireFox は使ったことがないので分かりませんが、おそらくシートダイアログを採用しているんでしょう。これでは、騙されにくくて安全かもしれません。ちなみに、Windows 版 FireFox はシートになりませんでした。

＞アクティブにならずに表の本物のウィンドゥにダイアログが出せるんなら、だまされる人も出そうだけど。

それができてしまうと、本当に脆弱性と言えると思いますよ。

Re:Mac OS X のシート

[NAT33 (17123)]

別にシートと同じものが表示されるとは書いていません。

Linuxの場合もWindowsの場合も同じくダイアログです。

ただ、同じくアクティブになった空白ウィンドゥに依存している点は同じということで。で、これがタブブラウザだと、画面全体が空白になるので、ひっかかる人は少ないだろうなというだけのこと。

Re:Mac OS X のシート

[targz (14071)]

＞別にシートと同じものが表示されるとは書いていません。
＞Linuxの場合もWindowsの場合も同じくダイアログです。

なんだ。そうなのですか。親コメントでは、

＞＞Fedora CoreでFirefox使っているが、件のデモだと、そのシートとやらと、ダイアログは同じような挙動してるんですが?

と書いてあったので、てっきり「Linux 版 FireFox はシートみたいな挙動 (ダイアログがにゅるっと降りてくる) をするのだと読んでしまいました。

ということは、ダイアログは一瞬でパッと表示されるものの、親となるウィンドウを隠さずに、タイトルバーのすぐ下に出るということでしょうか。

# 言葉で動作を書くのはむずかしい……。

Windows 版 FireFox だと JavaScript ダイアログが親ウィンドウを隠してしまっています。これは騙されそうです。

＞で、これがタブブラウザだと、画面全体が空白になるので、

NewWindows() もタブで表示させる設定だと、そうなりますね。NewWinodw() は新規ウィンドウにする設定だと騙されてしまいそうです。

Re:Mac OS X のシート

[G7 (3009)]

垂幕かどうかはともかく、
「ウィンドウとダイアログがくっついている」ってのは
凄く大事なポイントっぽいですね。

最近思うんだけどさ、いまどきのGUIの「問題」の幾つかは、

        ○ウインドウを入れ子にする

ことによって、
解決しちまうんじゃなかろうか？

ウインドウとダイアログの関係もそう。
デスクトップじゃなく1つのウインドウの「中」に
ダイアログが出て、出てる間は下の(対応する)ウインドウのフォーカスを奪う、
という風にしておけば、それでいいわけで。

Windowsには(だったかな)MDIっていう入れ子窓みたいなのがあるが、
あれって親子関係は一段だけだし、
親は子を入れる枠として専用化されちゃうしで、
自由度低すぎ。
あれを

        ○多段の入れ子もアリ
        ○親も子も、専用化はしない。枠でも中身でも好きに表示しろ。
            (これは制約を設けないだけだから、処理や構造はべつに複雑にならないはず)
        ○(何かの役に立つだろうから)入れ子関係を、生成後に変更することができるようにする。
            (これでSqueakに手が届く…か？)
        ○上記のようなフォーカス奪い(それをDialogと称する)とか、透明化(Dashboardっすか(藁))とか、そういう仕組みも入れとく。
        ○いわゆるデスクトップ自体も、単に「ルートの窓」として定義(?)する。

ってな風にすると、大した仕組みを組み込まなくても、
結構色々使える(＆安全になる)んじゃないか？と思ってる。

ついでに、

        ○フォルダと、GUI描画(?)領域とを、同一視する。
        ○○X画面飛ばしと、NFSとが、同一視できる(ぉぃぉぃ
        ○ファイルとオブジェクトも同一視する
        ○○フォルダにボタンObjectを置いてフォルダを表示すれば、ボタン1つが載っているアプリの出来上がり。
        ○(別んとこでも書いたけど)メニューとフォルダ(と描画領域)も同一視。
        ○○フォルダにボタンを置いて左上隅に小さく表示(藁)すれば、それがメニュー。
        ○ファイル(特に実行ファイル)とプロセスを同一視つーか「同じ構造」とみなす。
        ○○ファイルをClone(PrototypeOOP用語)するとProcessだ。
        ○プロセスがGUI描画領域を持つということは、プロセス「が」フォルダを持つということ。

なんてのもどうかなーと。
(やばい。そろそろ非セキュアになってきたなあ)

Re:Mac OS X のシート

[oku (4610)]

○(何かの役に立つだろうから)入れ子関係を、生成後に変更することができるようにする。
(これでSqueakに手が届く…か？)

これ↑はちょっと自信がないんですが、

○多段の入れ子もアリ
○親も子も、専用化はしない。枠でも中身でも好きに表示しろ。
(これは制約を設けないだけだから、処理や構造はべつに複雑にならないはず)

(略)

○いわゆるデスクトップ自体も、単に「ルートの窓」として定義(?)する。

これってモロに今の X Window System なのではないですか？ 例えば、X でのスクロールバーとかメニューとかボタンって大抵 Window ですけど...

どちらかというと

ついでに、

以降の方が面白そうです。 :-)

# 実用に耐え得るかどうかは別で、
# あくまでアイディア実験として。
# というか、既にどこかの砂場でやられてそうな気がしますけど。

Re:Mac OS X のシート

[G7 (3009)]

>これってモロに今の X Window System なのではないですか？例えば、X でのスクロールバーとかメニューとかボタンって大抵 Window ですけど...

ええ。APIレベルではそうなんです。
Windowsでもそうですね。全部WindowHandleという概念で統一されてる。

が、ユーザ(UI)レベルから見れば、
各Widgetは各Widgetとして特殊化されてて
それらの共通性はむしろ隠蔽されてます。
WindowHandleみたいな概念はただの Widget実装の道具として
(つまりプログラマによって)使われてるだけ。

その自由度をユーザレベルにも開放(?)したいんです。

具体的には例えば、
「○多段の入れ子もアリ」
ってのが実際に実装されてるのって、あまり見かけません。
Windowsだと、よく知らないけどMFCの教科書とかにはMDIが必ず出てくるんで、
たぶんMFCがMDIという非多段窓をプッシュしてるんだろうと思います。
で、ゲンジツを見ると、そのアプリを作ったライブラリがMFCであろうがなかろうが、
MDIを採用してるアプリって、凄く多い。
(みんな洗脳されてるんだろなあ)
そしてXとかでも、MDIっぽいUIはしばしば見かけますが、
幾らでも入れ子をしよう！っていう発想で作られたUIは
あまり見かけません。
(こちらもみんな洗脳されてるんだろなあ)
これが俺としては残念なんです。

そんなわけで、俺が(ここで)言いたいWindowとは
APIレベルの話じゃなく、
世間でFormとかDialogとか呼ばれてる、いわゆる「窓」(ん？)です。
あれを、「○多段の入れ子もアリ」とかにしたいんです。

ちなみにDashboardネタを見てるうち [srad.jp]に思ったことだったりもします。
つまりDashboardとは、
Desktopという窓に、 Dashboardという窓(透明)を、
オーバーラップさせたものだ、と捉えればOKなんです。
(俺の理解が間違ってなければね：以下同文)
DashboardがVisibleかどうかはF12で切り替わる、と。
そして前述の通り、Dashboard窓にWidget(X用語じゃなくDashboard用語のほうの)窓を置ける、と。
で、
DashboardとかWidgetとかいう「特別な」ものをOSメーカが用意するよりも、
上記のように単純で(ユーザの手により)応用可能な仕組みが用意されてるほうが
いいんじゃないかなーと思ったんです。
例えばこの例だと、WidgetをDashboard(という名の窓)かDesktopか、
どっちに属しているか？をユーザがささっと変更できれば、便利なわけだし。
だいいちDashboardみたいなもの「を」ユーザが簡単に自作できるほうが、便利なわけだし。
だって、上記のようにすれば、単に「透明窓を用意する」「それをF12で出させる」だけで
できあがっちゃうんだもん…

＃そして、パクリだと訴えられませんようにと祈るわけです(わら

あと垂幕云々もそうですし。
というか今まで「ダイアログ」を独立した別窓[*]で出すというUIを採用してたのが間違っていたわけで。

[*]独立といっても、上記の定義(？)より、真に独立した窓はRootであるDesktopしかありません。
ここでいう独立とは結局、そのダイアログを出すキッカケになった窓(か、その更に元となった「アプリ」の窓)に
従属していない、ということです。

>以降の方が面白そうです。

ああ。ファイルとかアイコンとかオブジェクトとかの話は
前半の「窓」の話だけの話よりも、さらに広い話をしてますから。

オブジェクトの中にオブジェクト(たとえばディレクトリにファイル)を置くのは、すなわち
それ(のデフォルトビュー)のWidgetに入れ子関係を持たせるのと、等価だと見なしたい。

個人的には、MVCよりも、Mに「デフォルトビュー」が必ず１つついてるという方式のほうが、
判りやすいんじゃなかろうか？と思っています。
ほっといてもとりあえずデフォルトのビューは提供される、という世界です。

>既にどこかの砂場でやられてそうな気がしますけど。

そりゃそうでしょうね。
こんな単純なアイデアが既出じゃないとしたら、
俺は人類の未来に絶望せんとなりません(^^;