アカウント名:
パスワード:
OSの機構の延長でActiveXコントロールを使えるようにしたブラウザと、プラグイン用APIを実装したブラウザ。なにがどうやったっておんなじ土俵に上がるわけねぇんだよ。技術や利便性の優劣だけじゃない。設計思想があまりに違う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
老技術者の繰言(-1:オフトピック) (スコア:2, 興味深い)
もとをただせば、OLEがはじまりで、その後、COMだのActiveXだの名前を変えつつ、中身は何にも変わってないのが今のActiveXっつー仕掛けだろう。3.1の頃にもあったくらいだし、セキュリティなんてなくて当然。それをブラ
同じ土俵に上がった気もする (スコア:2, 興味深い)
今回のこのAPIというのは、単にブラウザ～プラグイン間における共通インタフェース（プラグインのメソッド・プロパティアクセスや、イベントハンドリング）を定めようとしているんですよねぇ。
このAPI仕様に沿って作成されるプラグインというのは、そのプラットフォームのネイティブアプリケーションのような形で作られると思うのですが、そうなると結局ActiveXと同じようなセキュリティ問題が発生するような気がします。
ひょっとしたらサンドボックスでプラグインを動作させるとかそういうことも書いてあるのかな（すんません、よく資料を読んでないです）。でもネイティブアプリで作られていたりすると、APIをトラップでもしないとダメなのかもしれませんが…
Re:同じ土俵に上がった気もする (スコア:1)
Webから勝手にダウンロードしてインストールしたりとか。
ブラウザのプラグインはJavaアプレットと違ってそんなに沢山のプログラムをダウンロードして実行するわけではないので別にサンドボックスに閉じ込めなくてもいいと思います。
Re:同じ土俵に上がった気もする (スコア:1)
＃ActiveXコントロール特有の問題が存在しないとも思えませんが。
しかし、どれが安全なプラグインなのかを見分けることは初心者には難しいことです。署名の確認はプラグインの開発元の証明書で行われ、スパイウェアの混入するようなプラグインの開発元にも、「信頼された証明機関」とされる機関からコード署名可能な証明書が発行されます。なぜなら、その証明書はプラグインではなくその開発元を証明しているに過ぎないからです。
で、そういうことを解決するには、Javaや.NETやFlashなどのサンドボックスを利用して機能制限のあるプラグインとするか、ブラウザやOSの開発元からプラグインの特定のバージョンへの信頼の派生を自動的にもっときめ細かに（配布元を信頼するのではなく独自に）確認する方法を確立しないといけないと思われます。
プラグインのバージョン毎に証明書を準備することは有名なプラグインなら可能だと思いますし、信頼度に段階をもたせて、安全なプラグインなら自動的なダウンロードを可能にする、などのことが可能な状態にならないと、信頼性警告ダイアログの本来の意味は発揮される事はないと思います。
つまり、初心者には一元的な信頼性確認元も必要だということです。
プラグインシステムの統一を図るなら、その辺まで踏み込んでほしいと思います。
Re:同じ土俵に上がった気もする (スコア:0)
Re:同じ土俵に上がった気もする (スコア:1)
信頼できないプラグインをほいほいインストールしちゃうユーザーは信頼できないプログラムだってインストールしちゃうでしょうし。
Javaアプレットみたいにどこの馬の骨だかわからないアプリケーションをどんどん実行するならともかく、プラグインは信頼した少数のプラグインだけをインストールすると思いますので大丈夫では。
その上でスクリプト等で危険なことができないようにするのは各プラグインの責任で、ブラウザ側で変に機能を抑制しない方が良いのでは。