-<para>
- The Windows version of <application>Privoxy</application> puts an icon in
- the system tray, which also allows you to change this option. If you
- right-click on that icon (or select the <quote>Options</quote> menu), one
- choice is <quote>Enable</quote>. Clicking on enable toggles
- <application>Privoxy</application> on and off. This is useful if you want
- to temporarily disable <application>Privoxy</application>, e.g., to access
- a site that requires cookies which you would otherwise have blocked. This can also
- be toggled via a web browser at the <application>Privoxy</application>
- internal address of <ulink url="http://p.p">http://p.p</ulink> on
- any platform.
-</para>
-
-<para>
- <quote>toggle 1</quote> means <application>Privoxy</application> runs
- normally, <quote>toggle 0</quote> means that
- <application>Privoxy</application> becomes a non-anonymizing non-blocking
- proxy. Default: 1 (on).
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>toggle 1</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- For content filtering, i.e. the <quote>+filter</quote> and
- <quote>+deanimate-gif</quote> actions, it is necessary that
- <application>Privoxy</application> buffers the entire document body.
- This can be potentially dangerous, since a server could just keep sending
- data indefinitely and wait for your RAM to exhaust. With nasty consequences.
-</para>
-
-<para>
- The <application>buffer-limit</application> option lets you set the maximum
- size in Kbytes that each buffer may use. When the documents buffer exceeds
- this size, it is flushed to the client unfiltered and no further attempt to
- filter the rest of it is made. Remember that there may multiple threads
- running, which might require increasing the <quote>buffer-limit</quote>
- Kbytes <emphasis>each</emphasis>, unless you have enabled
- <quote>single-threaded</quote> above.
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>buffer-limit 4069</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- To enable the web-based <filename>default.action</filename> file editor set
- <application>enable-edit-actions</application> to 1, or 0 to disable. Note
- that you must have compiled <application>Privoxy</application> with
- support for this feature, otherwise this option has no effect. This
- internal page can be reached at <ulink
- url="http://p.p">http://p.p</ulink>.
- </para>
-
-<para>
- Security note: If this is enabled, anyone who can use the proxy
- can edit the actions file, and their changes will affect all users.
- For shared proxies, you probably want to disable this. Default: enabled.
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>enable-edit-actions 1</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- Allow <application>Privoxy</application> to be toggled on and off
- remotely, using your web browser. Set <quote>enable-remote-toggle</quote>to
- 1 to enable, and 0 to disable. Note that you must have compiled
- <application>Privoxy</application> with support for this feature,
- otherwise this option has no effect.
-</para>
-
-<para>
- Security note: If this is enabled, anyone who can use the proxy can toggle
- it on or off (see <ulink url="http://p.p">http://p.p</ulink>), and
- their changes will affect all users. For shared proxies, you probably want to
- disable this. Default: enabled.
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>enable-remote-toggle 1</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-</sect3>
-
-<!-- ~ End section ~ -->
-
-
-<!-- ~~~~~ New section ~~~~~ -->
-
-<sect3>
-<title>Access Control List (ACL)</title>
-<para>
- Access controls are included at the request of some ISPs and systems
- administrators, and are not usually needed by individual users. Please note
- the warnings in the FAQ that this proxy is not intended to be a substitute
- for a firewall or to encourage anyone to defer addressing basic security
- weaknesses.
-</para>
-
-<para>
- If no access settings are specified, the proxy talks to anyone that
- connects. If any access settings file are specified, then the proxy
- talks only to IP addresses permitted somewhere in this file and not
- denied later in this file.
-</para>
-
-<para>
- Summary -- if using an ACL:
-</para>
-
- <simplelist>
- <member>
- Client must have permission to receive service.
- </member>
- </simplelist>
- <simplelist>
- <member>
- LAST match in ACL wins.
- </member>
- </simplelist>
- <simplelist>
- <member>
- Default behavior is to deny service.
- </member>
- </simplelist>
-
-<para>
- The syntax for an entry in the Access Control List is:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- ACTION SRC_ADDR[/SRC_MASKLEN] [ DST_ADDR[/DST_MASKLEN] ]
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- Where the individual fields are:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>ACTION</emphasis> = <quote>permit-access</quote> or <quote>deny-access</quote>
-
- <emphasis>SRC_ADDR</emphasis> = client hostname or dotted IP address
- <emphasis>SRC_MASKLEN</emphasis> = number of bits in the subnet mask for the source
-
- <emphasis>DST_ADDR</emphasis> = server or forwarder hostname or dotted IP address
- <emphasis>DST_MASKLEN</emphasis> = number of bits in the subnet mask for the target
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-
-<para>
- The field separator (FS) is whitespace (space or tab).
-</para>
-
-<para>
- IMPORTANT NOTE: If <application>Privoxy</application> is using a
- forwarder (see below) or a gateway for a particular destination URL, the
- <literal>DST_ADDR</literal> that is examined is the address of the forwarder
- or the gateway and <emphasis>NOT</emphasis> the address of the ultimate
- target. This is necessary because it may be impossible for the local
- <application>Privoxy</application> to determine the address of the
- ultimate target (that's often what gateways are used for).
-</para>
-
-<para>
- Here are a few examples to show how the ACL features work:
-</para>
-
-<para>
- <quote>localhost</quote> is OK -- no DST_ADDR implies that
- <emphasis>ALL</emphasis> destination addresses are OK:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>permit-access localhost</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- A silly example to illustrate permitting any host on the class-C subnet with
- <application>Privoxy</application> to go anywhere:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>permit-access www.privoxy.com/24</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- Except deny one particular IP address from using it at all:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>deny-access ident.privoxy.com</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- You can also specify an explicit network address and subnet mask.
- Explicit addresses do not have to be resolved to be used.
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>permit-access 207.153.200.0/24</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- A subnet mask of 0 matches anything, so the next line permits everyone.
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>permit-access 0.0.0.0/0</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- Note, you <emphasis>cannot</emphasis> say:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>permit-access .org</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- to allow all *.org domains. Every IP address listed must resolve fully.
-</para>
-
-<para>
- An ISP may want to provide a <application>Privoxy</application> that is
- accessible by <quote>the world</quote> and yet restrict use of some of their
- private content to hosts on its internal network (i.e. its own subscribers).
- Say, for instance the ISP owns the Class-B IP address block 123.124.0.0 (a 16
- bit netmask). This is how they could do it:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>permit-access 0.0.0.0/0 0.0.0.0/0</emphasis> # other clients can go anywhere
- # with the following exceptions:
-
- <emphasis>deny-access</emphasis> 0.0.0.0/0 123.124.0.0/16 # block all external requests for
- # sites on the ISP's network
-
- <emphasis>permit 0.0.0.0/0 www.my_isp.com</emphasis> # except for the ISP's main
- # web site
-
- <emphasis>permit 123.124.0.0/16 0.0.0.0/0</emphasis> # the ISP's clients can go
- # anywhere
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- Note that if some hostnames are listed with multiple IP addresses,
- the primary value returned by DNS (via gethostbyname()) is used. Default:
- Anyone can access the proxy.
-</para>
-
-</sect3>
-
-<!-- ~ End section ~ -->
-
-
-<!-- ~~~~~ New section ~~~~~ -->
-
-<sect3>
-<title>Forwarding</title>
-
-<para>
- This feature allows chaining of HTTP requests via multiple proxies.
- It can be used to better protect privacy and confidentiality when
- accessing specific domains by routing requests to those domains
- to a special purpose filtering proxy such as lpwa.com. Or to use
- a caching proxy to speed up browsing.
-</para>
-
-<para>
- It can also be used in an environment with multiple networks to route
- requests via multiple gateways allowing transparent access to multiple
- networks without having to modify browser configurations.
-</para>
-
-<para>
- Also specified here are SOCKS proxies. <application>Privoxy</application>
- SOCKS 4 and SOCKS 4A. The difference is that SOCKS 4A will resolve the target
- hostname using DNS on the SOCKS server, not our local DNS client.
-</para>
-
-<para>
- The syntax of each line is:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>forward target_domain[:port] http_proxy_host[:port]</emphasis>
- <emphasis>forward-socks4 target_domain[:port] socks_proxy_host[:port] http_proxy_host[:port]</emphasis>
- <emphasis>forward-socks4a target_domain[:port] socks_proxy_host[:port] http_proxy_host[:port]</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- If http_proxy_host is <quote>.</quote>, then requests are not forwarded to a
- HTTP proxy but are made directly to the web servers.
-</para>
-
-<para>
- Lines are checked in sequence, and the last match wins.
-</para>
-
-<para>
- There is an implicit line equivalent to the following, which specifies that
- anything not finding a match on the list is to go out without forwarding
- or gateway protocol, like so:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>forward .* . </emphasis># implicit
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- In the following common configuration, everything goes to Lucent's LPWA,
- except SSL on port 443 (which it doesn't handle):
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>forward .* lpwa.com:8000</emphasis>
- <emphasis>forward :443 .</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
-<!--
- See the FAQ for instructions on how to automate the login procedure for LPWA.
--->
- Some users have reported difficulties related to LPWA's use of
- <quote>.</quote> as the last element of the domain, and have said that this
- can be fixed with this:
-</para>
-
-<para>
- <literal>
- <msgtext>
- <literallayout>
- <emphasis>forward lpwa. lpwa.com:8000</emphasis>
- </literallayout>
- </msgtext>
- </literal>
-</para>
-
-<para>
- (NOTE: the syntax for specifying target_domain has changed since the
- previous paragraph was written -- it will not work now. More information
- is welcome.)
-</para>
-
-<para>
- In this fictitious example, everything goes via an ISP's caching proxy,
- except requests to that ISP:
-</para>