![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Privoxy は Web ページのデータを操作し制御するのに "アクション" という概念を使用しています。アクションファイルは、あるリクエストを処理する間に Privoxy が解釈する action が設定されています。典型的には、全ての URL に対してグローバルに適用されるデフォルトアクション一式を定義し、それから必要なら例外を追加することになるでしょう。それぞれ、あるいは全ての Web ページをどのように処理するかに対して、高度な制御と自由度をもたらす、様々なアクションが利用可能です。
アクションは URL パターンベース(つまり URL ごと)にも、Web サイト全体に対しても、あるいはそれらのグループや一部分に対しても定義できます。アクションは、いくつかを一緒にグループにまとめてから、単一あるいは複数のパターンにマッチするリクエストに適用することもできます。あるサイトに対して適用できるような、たくさんのアクションの選択肢があります。例えば、デフォルトアクションでクッキーをブロックしているとして、あるサイトからのクッキーを受け入れる必要があるとします。いずれかのアクションファイル、恐らくは user.action に、そのサイトに対する例外を定義する事になるでしょう。
アクションという概念についての包括的な議論は、ユーザーマニュアルのアクションファイルの章を参照してください。全てのアクションのリストと、アクションファイルに対する入門用チュートリアルもあります。
アクションファイルは特別な構文を持つ単なるテキストファイルです。テキストエディタで編集可能です。しかし、恐らく一番簡単な方法は Web ブラウザで http://config.privoxy.org/ (短縮形は http://p.p/) にある Privoxy のユーザーインタフェースにアクセスして、メニューから "View & change the current configuration" を選択する事です。メイン設定ファイル(config)でこの機能を明示的に有効にする必要がある点に注意してください。メイン設定ファイル(config)の enable-edit-actions を参照してください。
詳しい説明については、ユーザーマニュアルのアクションの章を見てください。
あなたのフィードバックと継続的な開発をもとにして、default.action の更新版は随時我々のプロジェクトページの files セクションで得られるでしょう。
Privoxy やアクションファイルの更新がリリースされた時に e-mail の通知を受けたいならば、アナウンス用メーリングリスト ijbswa-announce@lists.sourceforge.net を購読してください。
設定ファイルの構文と目的は、3.x シリーズ中では大体同じままですが、後方互換性は保証されていません。各リリースは更新され、"改善された"バージョンを含んでいますから、新しい設定ファイルをインストールし、自分の変更をマージすることを強く推奨します。
"複雑"というのは見る人次第です。例えば正規表現の構文といったような、基になっている概念をよく知っている人ならば、水を取り込む魚のごとく取り込む事ができるでしょう。また、ユーザーフレンドリーであろうと努力するソフトウェアは、往々にして、精巧さと自由度に欠けます。力と使いやすさの間には常にトレードオフがあります。さらに、誰でも自由に Privoxy を強化するアイデアと実装に貢献できます。
初期設定はこれらのサービスの利用に影響を与えないはずです。しかし、全てのクッキーを一時的なものにするので、セッションをまたがる場合にログイン情報をブラウザが忘れてしまいます。アクセスする度に毎回手動でログインしたくなければ、user.action ファイルのなかで該当サイトに対するクッキー処理を単純に off にしてください。Yahoo の場合、以下の例のようになるでしょう。
# Yahoo ログイン用のクッキーを許可する(訳註：Yahoo Japanではありません)
#
{ -crunch-incoming-cookies -crunch-outgoing-cookies -session-cookies-only }
.login.yahoo.com
この種のサイトは大抵 Javascript を使用し、複雑かつ重厚なので「壊れやすい」です。依然として問題があるならば、そうした厄介な状況用のエイリアスがあります。
# Gmail は「壊れやすい」(fragile)サイト
#
{ fragile }
# Gmail は
mail.google.com
この種の変更を行ったらいつでも、変更が反映されるように忘れずブラウザのキャッシュを削除(flush)してください。
同様に、ドメイン、ホスト、パスが適切であることを確認してください。ブラウザは今現在どこにいるかを明確に示せるので、その情報を設定中で使うべきです。上記の例で(これも有効なドメイン名ではありますが) gmail.com としては参照されていない点に注意してください。
Privoxy を設定する事は完全に自明というわけではありません。入門の手助け用に、http://config.privoxy.org/show-status にある Web ベースのアクションファイルエディタでは、3 種類の異なるデフォルトアクションの「雛形」を提供しています。アクションのリストと、どのようにデフォルトの雛形を設定するかについてはユーザーマニュアルを参照してください。
これらのデフォルト設定によって正常動作しないサイトのために、既知で一般的な「問題のある」サイトに対する例外設定が含まれてはいますが、一般的には、より積極的なデフォルト設定を使えばより多くの例外を設定する必要があるでしょう。新規ユーザーは "Cautios(慎重)" な設定から始めるのが最良です。最も安全で、最も問題が少ないでしょう。より詳細な議論についてはユーザーマニュアルを参照してください。
"Advanced(高度)" な雛形(以前は "Adventure(冒険的)" な雛形と呼ばれていました)はより積極的で、Privoxy の高度な機能を活用している点は指摘しておくべきでしょう。自己責任で使用してください。
(訳註：以下、UNIX 環境を基に記述されています) /etc/privoxy 以下の階層全てがユーザー "privoxy" に属し 644 のパーミッションしか持たないのに、普通のユーザーが設定ファイルをブラウザで編集できる事が奇妙に思えるかも知れません。
ブラウザベースのエディタを使っている時には、Privoxy 自体が設定ファイルに書き込んでいます。Privoxy は、ユーザー "privoxy" として動作している為、自身の設定ファイルを更新できます。
(例えば LAN 上などで)Privoxy を複数の信頼できないユーザーに対して動作させていたり、ブラウザを完全には管理下に置けなかったりする場合には、恐らく "enable-edit-actions 0" と "enable-remote-toggle 0" をメイン設定ファイルに設定する事で、Web ベースのエディタとリモートでの切り替え機能をオフにしなければならないでしょう。
Privoxy 3.0.7 の時点で、これらのオプションはデフォルトで無効になりました。
default.filter ファイルは、開発者によって提供されたフィルタが定義されているファイルです。フィルタは、Web ページの内容やヘッダをその場で変更したり削除したり出来る、アクションの特別な部分集合です。コンテントフィルタは、ページのソース内にある何にでもに適用可能です。ヘッダフィルタはサーバーかクライアントのヘッダに対して適用可能です。これを実現する為に、正規表現が使用されています。
共通のイライラ(annonyance：広告等)に対処するために、たくさんのフィルタが予め定義されています。フィルタはここでは定義されるだけで、呼び出すためにはいずれかのアクションファイルで filter アクションを使う必要があります。コンテントフィルタは不適切な MIME タイプに対して自動的に無効にされますが、何に対してフィルタを適用するべきで、何に対して適用するべきでないかを、Privoxy よりもよく知っているという場合には、どんな内容に対してもフィルタを適用する事が出来ます。
フィルタとブロックを取り違えないようにしましょう。ブロックは全く異なるアクションであり、より典型的に、広告や望まないサイトのブロックに使用されます。
正規表現や HTML を良く知っている場合には、提供されている default.filter をテキストエディタで開いて、自分のフィルタを定義できるでしょう。これは潜在的に非常に強力な機能ですが、正規表現と HTML/HTTP の両方に対する専門的な知識が必要です。デフォルトフィルタに対する変更や、新しく作成するフィルタは、アップグレード中に上書きされないように、user.filter のような別のファイルに置くべきです。複数のフィルタファイルを定義する機能は、v.3.0.5 以降の新しい機能です。
設定ファイルのこの部分に対しては GUI エディタがありませんが、Web ベースのアクションファイルエディタで、default.filter に含まれる種々の予め定義されたフィルタを有効/無効にすることはできます。メイン設定ファイル(config)でカスタムアクションエディタを明示的に有効にする必要がある点に注意してください。メイン設定ファイル(config)の enable-edit-actions を参照してください。
自分自身のフィルタを開発したいなら、Privoxy-Filter-Test を見た方が良いでしょう。
初期設定では、Privoxy は 127.0.0.1 (localhost) からのリクエストに対してのみ応答します。ネットワークに対してサーバとして動作させる為には、この動作をメイン設定ファイルで変更する必要があります。# でコメント化されているかもしれない listen-address オプションを探してください。コメントから通常行に戻して、LAN のゲートウェイインタフェースのアドレスと使用するポート番号を割り当ててください。LAN のアドレスが 192.168.1.1 で、Privoxy を 8118 番ポートで動作させたいと仮定すると、次のようになるでしょう。
listen-address 192.168.1.1:8118
ファイルを保存して、Privoxy を再起動してください。それからネットワーク上の全てのブラウザに対してこのアドレスとポート番号を(訳註：プロキシとして)使用するよう設定してください。
あるいは、Privoxy を全ての有効なインタフェースに対して listen させることも出来ます。
listen-address :8118
それから接続を制限するために、Privoxy の permit-access 機能を使ってください。同様にファイヤーウォールの使用も推奨されます。
上記ステップは、OS に関わらず全ての TCP ネットワークについては同じはずです。
信頼できないユーザーのいる LAN 上で Privoxy を実行する場合には、アクセス制御とセキュリティオプションを二重チェックする事を推奨します。
ブロックされたイメージの置き換えについては、set-image-blocker アクションで制御できます。市松模様、透明の 1x1 サイズの GIF 画像(別名："blank")、あるいは好みの画像へのリダイレクトを選択可能です。この選択は画像としてブロックされた画像(つまり、handle-as-image と block の両方のアクションにマッチした URL)にだけ有効である点に注意してください。
何も見たくない場合は、set-image-blocker アクションを "blank" に変更してください。user.action ファイルを編集するか、Web ベースのアクションファイルエディタで設定可能です。
どの画像が広告でどの画像が広告でないかは経験に基づく推測であることを思い出してください。標準の設定はかなり賢いはずだと願っていますが、時たま間違える事もあるでしょう。市松模様の画像は見た目的にそう悪くなく、かつ、どの画像がブロックされたのかを示します。これは、ナビゲーションの助けとなる、あるいは無実である画像が誤ってブロックされた場合に大変役立つ可能性があります。新しいユーザーには、何が起こっているかが「見られる」ようにしておくことを推奨します。どれだけのバナーを見なくて済んだか見る事を楽しむ人々もいるかも知れません。
これは、バナーがページの HTML に直接埋め込まれているのではなく、(i)frame や (i)layer といった別の HTML 文書に分離されていて、それらの外部 HTML 文書がブロックされた場合に発生します。HTML 文書をリクエストした場合、ブラウザは HTML のみを予期しかつ受け入れるので、代替画像ではなく代替 HTML ページとして置き換えられることになります。そうでないと技術的に動作しません。
代替ページは利用可能なスペースに適応し、小さなフレームに読み込まれた場合は小型の 2 行形式で、スペースが許すなら大きな赤い "BLOCKED" バナーのある完全版で自分自身を表示します。
画像としてバナーをブロックしたい場合には、それらが埋め込まれている HTML 文書がブロックされないようにする必要があります。代替ページにある "See why" リンクをクリックすれば、どのルールによってページがブロックされたかが表示されます。そのルールを変更し HTML 文書をブロックしないようにした後なら、ブラウザは実際のバナー画像を読み込もうとし、(うまくいけば)通常の画像ブロックが実行されるでしょう。
はい。完全な Windows サービス機能がバージョン 3.0.5 で導入されました。Privoxy をサービスとしてインストール、設定する方法の詳細は、ユーザーマニュアルを参照してください。
3.x 初期版は、srvany.exe を使用する事でシステムサービスとして実行できます。詳細は http://sourceforge.net/tracker/?func=detail&atid=361118&aid=485617&group_id=11118 にある議論とサンプル設定を参照してください。
これは可能で、Privoxy の利点と他のプロキシの利点を組み合わせられるため、しばしば 便利です。実現方法が記述されているユーザーマニュアルの転送の章と、後述の「Tor と一緒に動作させるにはどうしたらいいですか？」の章を参照してください。
いいえ。それよりももっと複雑です。これは「横取り型(intercepting)」プロキシ と呼ばれる特殊なプロキシの場合にだけ動作します。
あらゆる方法でクライアントのリクエストとサーバーのレスポンスを変更することが Privoxy の趣旨ですから、RFC2616 に記述されている透過型プロキシではありません(訳註：RFC2616 ではプロキシの認証と識別に必要なこと以外、リクエストもレスポンスも変更しないプロキシのことを transparent proxy として規定しています)。
しかし、「横取り型プロキシ(intercepting proxy)」として「透過型プロキシ(transparent proxy)」という人もいます(訳註：というか、ぱっと検索した限りでは日本語圏ではそういう使い方しかなさそうです)。もしあなたもそのうちの一人なら、次の項目を読んでください。
Privoxy は通信自体を横取りすることができませんが、Host ヘッダが存在する限り(PF や iptables といった)パケットフィルタで横取りされリダイレクトされた要求を処理する事は出来ます。
HTTP/1.1 では Host ヘッダが必要であり、また、いずれにしろほとんどの Web サイトが Host ヘッダを頼りにしている為(訳註：恐らく一つの IP アドレスで複数の Web サイトを提供するいわゆる「名前ベースのバーチャルホスト 」のことだと思われます)、この制限は問題にはならないはずです。
通信を横取りして、Privoxy にリダイレクトする方法を学ぶ為にパケットフィルタのドキュメントを参照してください。その後で必要なのは、横取りされた要求を受け入れるように Privoxy を設定することだけです。
Office 2007 より前のバージョンの Outlook は、Internet Explorer のコンポーネントを HTML の描画と、HTML メール に埋め込まれているかもしれない要素に対する HTTP リクエストの処理の両方に使用していました。そのため、IE (少なくとも古いバージョンの Internet Explorer )で Privoxy を動作させるよう設定すれば、自動的にその設定が共有されるはずです。
Office 2007 からは、Outlook は代わりに MS-Word の描画エンジンを使用します。プロキシを使用するよう設定できるかどうかは不明です。
結果だけ言うと、できません。Privoxy には、どのアプリケーションがリクエストを出したのかを知る方法が有りません。そのため、Web ページと HTML メールを区別する方法も有りません。Privoxy は盲目的に全てのリクエストを中継します。Outlook Express の場合(上記項目も参照してください)、何分 IE を使用していますので、Privoxy にはどうやっても区別する方法が有りません。他のどんなプロキシ系アプリケーションにも不可能です。
プライバシーやセキュリティに関する点も含んだ良い議論がありますので、 http://sourceforge.net/tracker/?func=detail&atid=211118&aid=629518&group_id=11118 を参照してください。
クッキーはいくつかの方法で設定する事が出来ます。古典的な方法は Set-Cookie HTTP ヘッダによるものです。これは素直で、かつ、Privoxy の sesson-cookies-only のように簡単に操作できる方法です。Javascript を使用して Cookie を設定することも出来ます(Privoxy ではコンテントクッキー(content -cookie)と呼んでいます)。これは構文の幅が広くて若干の当て推量を必要とするので、罠にはまりやすいです。Javascript を無効化することで全てに対応しようとするのは、多くのサイトを動作させなくするため非現実的です。最後に、Javascript によって張られた HTTP/SSL のセキュアなセッションにクッキーが埋め込まれていた場合、Privoxy には手が出せません。
まとめると、Privoxy は、一般的にクッキーを管理する助けになりますし、クッキーによるプライバシーの損失を最小化する助けにもなりますが、現実的には全てのクッキーを止めることはできません。
いいえ。実際にはクッキーの使用にはたくさんの利点があります。クッキーは、ブラウザがページ間あるいはブラウザのセッション間でデータを維持することができる方法に過ぎません。そうすることが必要な場合もあり、結果としてユーザーにもちょっとした利点があります。しかし、こうした信頼を利用して、自らの目的の為にあなたからこつこつと集めてきた情報やあなたのブラウザ習慣を利用し、あなたに潜在的な被害を与えているもしれない Web サイトの長い歴史があります。そのようなサイトはあなたを利用してあなたのシステムに彼らのデータを保存しています。これがプライバシーに敏感な人たちがこのようなクッキーがどこから来たのかを注視する理由であり、 このようなクッキーが本当にそこに存在しようとする理由なのです(原文：That is why the privacy conscious watch from whom those cookies come, and why they really need to be there.)。
詳細は Wikipedia のクッキーの定義を参照してください。
クッキーに関連したいくつかのアクションがあります。デフォルトの動作は「セッション内クッキー(session cookie)」すなわち、現在のブラウザセッションに対してのみ継続するクッキーのみを許可する、です。これにより、クッキーに関連した悪用をほとんど除去できます。しかし、クッキーを継続させたい場合もあるかもしれません。
example.com に対してクッキーに関する全てのアクションを無効化する、すなわち入出力双方を無制限に許可する場合には、
{ -crunch-incoming-cookies -crunch-outgoing-cookies -session-cookies-only -filter{content-cookies} }
.example.com
上記を user.action に記述してください。いくつかのアクションは初期設定でオフになっているかもしれないので冗長かも知れませんが、何をしたいかを明示的にしておくことに害はありません。user.action はこのような状況の為に allow-all-cookies という alias を含んでいます。
listen する TCP ポート番号のような属性も含めて、個々の Privoxy のインスタンスはそれぞれの設定を持っています。それぞれ独自の listen-address 設定とパス設定を行った複数のインスタンスの Privoxy を実行し、独自の設定を持つように出来ます。ポート単位の設定だと考えてください。
数人のユーザーに対しては十分単純ですが、大規模な導入では設定を共有するユーザーのグループ化を考えるべきでしょう。
もちろんです。単純なホワイトリスト設定の為にいくつかできることがあります。以下は非常に簡単な例です。
############################################################
# ブラックリスト
############################################################
{ +block }
/ # 「全ての」URLをブロックする
############################################################
# ホワイトリスト
############################################################
{ -block }
kids.example.com
toys.example.com
games.example.com
最初に全ての URL をブロックし、続いて 3 つの特定の例外を許可する事で、3つのサイトだけアクセス可能にします。
別のアプローチとして信頼された referrer の概念が組み込まれた Privoxy の trustfile の概念があります。詳細はドキュメントの Trust (訳註：trustfile)の項を参照ください。
これらはかなり単純なアプローチであり、完全に万能というわけではありません。設定ファイルを編集して簡単にホワイトリストを回避したり出来ないように、無効化するべき種々の設定オプションがあります。ここ以外のどこかやユーザーマニュアルに記述されています。
広告のブロックは Privoxy の種々のアクションの複雑な適用によって実現されています。これらのアクションは、単純な画像、バナー、フラッシュのアニメーション、テキストページ、JavaScript、ポップアップ、pop-under 等に対して配備されており、一つ二つのアクションをオフにすればよいというような単純さではありません。Privoxy の広告ブロック機能を構成する様々なアクションは初期設定ファイルにハードコーディングされ(訳註：≒直接書き込まれ)ています。Privoxy を使う全ての人がこの機能に興味を持つと仮定されていました。
広告ブロックなしにしたい場合には、いくつか可能なアプローチがあります。default.action 内のたくさんのブロックルールを手動で取り消せます。あるいはもっと簡単に、独自の default.action ファイルを広告ブロックルールとその例外なしに最初から作ることもできます。あるいは、プライバシー的な理由から実行されている追加のブロックについても気にしないならば、あなたの user.action で下記の単純なルールによって広告ブロックを上書きすることも非常に簡単にできます。
# 誰でもどこでもブロックしない
{ -block }
/ # 「全て」のURL をブロックしない
あるいは、もっと包括的に様々な広告関連のアクションを無効化するならば
# 誰でもどこでもブロックせず、適当なフィルタリング等もオフにする
{ -block \
-filter{banners-by-size} \
-filter{banners-by-link} \
allow-popups \
}
/ # 「全ての」URL をブロックせず広告を許可する
複文(訳註：{} のこと)中の最後の「アクション」allow-popups は様々なポップアップブロック機能を無効化するエイリアスです。
Privoxy の「テンプレート」は様々な目的によって Privoxy が利用する特殊化されたテキストファイルであり、テキストエディタで簡単に編集できます。全てのテンプレートページは適切な名前のサブディレクトリ、すなわち templates ディレクトリ内にインストールされています。HTML の構文について知っている事はもちろん助けと成るでしょう。
あらかじめ警告しておくと、デフォルトのテンプレートはアップグレード中に上書きしていまいやすいです。しかし、全く新しいテンプレート群を作成して別のディレクトリに保存し、メイン設定ファイル(config)で別のパスを指定する事ができます。詳細は、templdir オプションを参照ください。
やり方は一つではありません(原文：There is more than one way to do it)。Perl は関係有りませんが(訳註：There's More Than One Way To Do It は Perl のスローガンで Perl コミュニティではしばしば TMTOWTDI と表記される)。
BLOCKED テンプレートページを編集することで(前項参照)、思いとどまるユーザーもいるかも知れませんが、この方法は簡単に回避されます。必要な制御のレベルによっては、Privoxy をソースからビルドしてコンパイル時のオプションとして設定可能な種々の機能を無効\化する方が良いでしょう。以下のようにソースを設定するべきです。
./configure --disable-toggle --disable-editor --disable-force
ハードコードされた(訳註：埋め込まれていて簡単に変更できない)セキュリティ機能をもつ実行形式が作成されますので、ブロックされたサイトを簡単にバイパスすることや、接続ユーザーの Web ブラウザによって現在の設定ファイルを変更することができなくなります。
最後に、これらの機能全ては Privoxy のメイン設定ファイル中のオプションでオン、オフを切り替えることもできますので、再コンパイルする必要は有りません。
