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

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

[Anonymous Coward]

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

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

GUIがまだ足らない。

[Anonymous Coward]

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

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

Mac OS X のシート

[targz (14071)]

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

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

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に「デフォルトビュー」が必ず１つついてるという方式のほうが、
判りやすいんじゃなかろうか？と思っています。
ほっといてもとりあえずデフォルトのビューは提供される、という世界です。

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

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