「クローズドで改造版を公開するために GPL から BSD ライセンスへの変更を求める事例」記事へのコメント

ブラウザ上でやった方がいいんじゃないかなぁ

[qoult (41103)]

ライセンスとは全然関係ないですが・・・

ずっと昔、Proxomitron が無くなり Proximodo の開発が始まったころだったと思うのですが、自分もいわゆるコンテントフィルタリングHTTPプロキシの開発に参加(もしくは自作)しようと思っていたことがあります。ただ、コンテントフィルタリングはブラウザ上で行なうべきなのではないだろうか(例えばGreasemonkeyやStylishなどのように)。と思って結局開発には参加しませんでした・・・。

ブラウザ上で行なうべきだと考えた理由としては、

• - HTML文書に対して単純なテキストマッチングを行なうだけだと、例えば属性の順番が違うとか、スペースのあるなしとか、属性値がダブル/シングルクォートで囲われているかとか、実体参照とかに対応するのが難しい(Proxomitronでもそうだったけど、パターンが複雑になりすぎる)。そうすると、プロキシ上でHTMLをパースして(SAXのような感じで)、それを元にマッチングや書き変えを行なう必要があるけど、世の中のHTML文章には文法エラーが非常に多いし、そういった文法エラーがあった場合の扱いをブラウザと一致させなきゃいけない。
• - HTML文書の文字エンコーディングが指定されてない場合、文字エンコーディングを推測しなきゃいけない。
• - HTTP 1.0 の頃は問題なかったけど、HTTP 1.1 ではコンテントヘッダで Content-Length を指定しなきゃいけない(HTTPコネクションを維持するため)。コンテントボディを書き換えた場合、それに応じてヘッダを書き換えなきゃいけないため、コンテントボディを全て読み込んで書き換えが終わり、コンテントボディの長さが分かるまでブラウザにはデータが送れなくなってしまう。それを回避するには、コンテントボディ全体を chunked コーディング(Transfer-Encoding: chunked)に変換しなければならない。
• - コンテントボディが最初から chunked コーディングになっていた場合は、それをデコードしてからマッチングと書き変えを行い、また chunked コーディングに変換しなおしてブラウザに送る事になる。
• - コンテントボディが圧縮されていた場合(Content-Encoding: gzip など)、プロキシ上でそれを一旦展開しなきゃいけない。
• - HTTPSなページは書き換えられない。それを回避するためには、中間者攻撃のような感じで、プロキシが独自に発行する証明書をブラウザに信頼させて、ブラウザから送られたHTTPSトラフィックをプロキシ上で復号した上で、改めてプロキシがサーバーへHTTPS接続を行なう必要がある。証明書の確認や失効の処理について、今まではブラウザが行なっていたものを、プロキシが責任を持ってやらなきゃいけなくなる。
• - 結局、ブラウザが行なっている処理の結構な部分をプロキシ上で実装しなきゃいけない。全てのネットワークトラフィックを(ローカルにあるとはいえ)プロキシを通すのはなんかリソースがもったいない気がするし、ブラウザが行なう処理をプロキシも行なうというのも二度手間感がある。

とかいう理由だったような記憶があります。

実際にブラウザ上でユーザースクリプトやユーザースタイルシートを使っていると「単純なテキスト置換でも実現できる事、むしろそのほうが手っ取り早い事」というようなケースもあるのですが、「もしやるのであれば、ブラウザのネットワーク入出力をフックして、そこで書き換えた方がいいのではないだろうか」と思ってます。

Re:

[Anonymous Coward]

俺もまったくそう思う。
ブラウザでユーザスクリプトが使えなかった時代には Proxomitron のようなソフトも需要があったと思うし、
実際に自分も使っていたけど、今は全部ユーザスクリプトでやってる。 広告の除去なんかは adblock があるしね。
Proxomitron が 2003 年初出で Greasemonkey が 2004年だから、Proxomitron はそういう時代を反映した応急処置的なツールだったのかもしれない。