2005年8月アーカイブ

高木浩光＠自宅の日記の記事『携帯電話の「フルブラウザ」は何を約束する言葉か』によれば、、携帯電話のJavaアプリレベルの自称「フルブラウザ」のSSL対応は SSL対応とは呼べないものがあるようですね。 Javaアプリの制限の関係で、基本的にアプリの置かれたサーバしかアクセスしか 出来ないため通常は、一種のproxyを実装しているわけですが、 少なからぬものでアプリとproxy間が暗号化されていないためSSLとは呼べない 状況のようです。

フィッシング対策協議会のサイトが右クリック禁止を実施という話が高木浩光@自宅の日記に『フィッシング対策協議会のサイトが右クリック禁止を実施』としてポストされています。先日の自称HTML暗号化ソフトもそうですが何のための右クリック禁止かというのが完全に手段のためには目的を選ばずになっています。ブラウザが少なくとも初期時点において平文のHTMLしか理解しない以上、どんな手法でも完全にソースを伏せることは不可能なんですがね。

まあ、もう一本のアーティクルの『「常に新しい」新銀行東京は時代に取り残されていた』も戦慄を通り越して失笑の領域に達する日本のe-Commerceサイトの実態を突いています。もはや、アドレスバーを隠すなんていうのはセキュリティ上好ましくないサイトデザインであることは言うに及ばずです。アドレスバーの詐称の危険があったとしても、それは例外的な自体でありサイトを信頼するかどうかの情報を得るのにアドレスバーは必要な情報です。

こういう、愉快なサイトデザインをやっといて、「安全性と使いやすさにこだわった」と書く神経は その存在自体が信じがたいものがあります。安全性と使いやすさにこだわる銀行は右クリック 禁止のような Web ブラウザの基本機能の制限や、アドレスバーの除去のような 根本的にフィッシングに脆弱なサイトデザインをしないと思うのですが。

何のためのデザインかを忘れ、デザインのためのデザインと化しているのでは手段のためには目的を選ばずです。

ITmediaの『あなたのアプリケーションは大丈夫？ ～ .NET Framework 2.0上での1.1アプリケーションの動作』で.NET Frameworkのバージョン間の互換性に関する記事が上がっていますが、いまいちわかりやすい文章になっていないようです。

まず、基礎的な事項について整理すると、.NET Frameworkで実装されたアプリケーションの場合、アセンブリに開発時に使用された.NET Frameworkのバージョンを示す情報があります。これにより、デフォルトで使用されるランタイムのバージョンの既定値が得られます。例えば、バージョン 1.1で開発された場合は基本的にはバージョン 1.1のランタイムで実行しようとします。

.NET Frameworkはいわゆるサイドバイサイドで展開できるので、.NET Framework 2.0をインストールしても 1.1がなくなるわけではありません。そのため、1.1と2.0を両方インストールすれば 1.1で開発したアプリケーションは 1.1のもとで実行されます。問題になるのはCOMコンポーネントとして.NET Frameworkのアセンブリが実行された場合で、この場合、依存するアセンブリがどのバージョンなのかは不明のため、現在は 2.0で実行しようとします。もちろん、2.0のランタイムが存在した場合ですが。したがって、2.0の変更で引っかかる場合には問題になります。この場合は、configファイルを展開することで 1.1での実行を強制する必要があります。