+
+92) The statistics currently aren't calculated correctly by Privoxy
+ as each thread is only counted as one request which is no longer
+ correct. This should be fixed, or the statistic code removed.
+ Privoxy-Log-Parser's provides more detailed statistics, anyway.
+
+93) Add a config directive to let Privoxy explicitly request either
+ IPv4 (or IPv6) addresses, even if the system supports both.
+ Could be useful as a workaround for misconfigured setups where the
+ libc returns IPv6 addresses even if there's no IPv6 connectivity.
+
+94) Add a config directive to let Privoxy prefer either IPv4 (or IPv6)
+ addresses, instead of trusting the libc to return them in an order
+ that makes sense. Like #93, this could be useful as a workaround
+ for misconfigured setups.
+
+96) Filters should be easier to look up. Currently get_filter() has to
+ go through all filters and skip the filter types the caller isn't
+ interested in.
+
+98) When showing action sections on the CGI pages, properly escape
+ line breaks so they can be copy&pasted into action files without
+ adjustments.
+
+99) Figure out a mechanism through which a user can easily enable
+ site-specific action sections that are too aggressive to be
+ enabled by default. This could be similar to the presettings
+ in default.action, but could also be just another action file
+ that isn't used by default.
+
+100) Create a cross-platform Privoxy control program and retire
+ the win32 GUI. Integrate support for Privoxy-Regression-Test,
+ Privoxy-Log-Parser, Privoxy-Filter-Test, uagen and similar tools.
+ Interested donors: 1.
+
+102) Add an include directive to split the config file into several parts.
+
+103) Potential performance improvement for large action files:
+ when figuring out which actions apply, check the action bit mask
+ before pattern matching and skip section that wouldn't modify the
+ actions already set. To increase the impact the sections would have
+ to be applied in reverse.
+
+104) The code to modify global_toggle_state should be factored out into
+ a separate function. Currently we mess with it in three different
+ files, but only in w32log.c the tray icon is explicitly set.
+ The logging is inconsistent as well. For details see #3525694.
+
+106) actionlist.h should be embedded in a way that causes less text
+ segment bloat.
+
+107) Support more pcrs variables, for example $destination-ip-address
+ and $source-ip-address.
+
+108) Allow to use a somewhat random string instead of PRIVOXY-FORCE.
+
+109) Let log_error() support the format specifier %S which should
+ work like %s but escape new lines like %N. This would be useful
+ to log the result of header filters which may inject new lines.
+
+110) Add a global-buffer-limit directive that roughly limits how
+ much malloc'ed memory Privoxy will use and can potentially
+ be smaller than (buffer-limit * max-client-connections).
+
+111) Reject requests if hosts and ports in request line and Host
+ header don't match (before filters have been applied).
+
+112) If a header filter is used to inject another header by inserting
+ a \r\n (undocumented feature), detect it and split the headers so
+ following header actions do not treat them as a single string.
+ Alternatively add another header injection mechanism.
+
+113) Log statistics upon receiving a certain signal (SIGINFO or SIGUSR1).
+
+114) Properly deal with status code 100. The current "Continue hack"
+ can cause problems for gpg when uploading keys through Privoxy.
+
+115) Add ICAP (RFC 3507) support. FR #3615158.
+
+116) Due to the use of sscanf(), Privoxy currently will fail to properly
+ parse chunks whose size can't be represented with 32 bit. This is
+ unlikely to cause problems in the real world, but should eventually
+ be fixed anyway. See also:
+ https://bugzilla.mozilla.org/show_bug.cgi?id=959100
+
+118) There should be "escaped" dynamic variables that are guaranteed
+ not to break filters.
+
+120) Add an option to limit pcre's recursion limit below the default.
+ On some platforms the recursion limit doesn't prevent pcre from
+ running out of stack space, causing the kernel to kill Privoxy
+ ungracefully.
+
+121) Add HTTP/2 support. As a first step, incoming HTTP/1.x requests
+ should be translated to outgoing HTTP/2 requests where possible
+ (and if desired by the user).
+ Interested donors: 1.
+
+122) Allow customized log messages.
+
+124) Add support for the "lightweight OS capability and sandbox framework"
+ Capsicum. http://www.cl.cam.ac.uk/research/security/capsicum/
+ Interested donors: 1.
+
+125) Allow clients to HTTPS-encrypt the proxy connection.
+ Interested donors: 1.
+
+126) Run the Co-Advisor HTTP compliance tests, evaluate the results,
+ fix the compliance issues that aren't by design and document
+ the rest.
+ Note that Privoxy developers qualify for free account upgrades:
+ http://coad.measurement-factory.com/details.html#pricing
+
+127) Add "real" CGI support (serve program output instead of forwarding
+ the request). The work is mostly done due to +external-filter{}.
+
+128) Add a config directive to control the stack limit.
+
+129) Completely implement RFC 7230 4.1 (Chunked Transfer Coding).
+ Currently Privoxy doesn't properly deal with trailers which
+ are rarely used in the real world but should be supported anyway.
+
+130) Move header_tagger() out of the parser structs and let it execute
+ taggers one-by-one against all headers so the header order has less
+ influence on the tagging result. As a bonus, dynamic taggers would
+ have to be compiled less often.
+
+131) The handle-as-empty-doc-returns-ok directive should be replaced with
+ an action so the behaviour can be enabled on a per-request basis.
+ Interested donors: 1.
+
+133) Consider allowing bitcoin donations.
+ Interested donors: 2.
+
+134) Track the total number of bytes written to and received from a socket.
+
+135) Add OpenBSM audit support.
+
+136) Make builds reproducible.
+
+138) Bring back the scripts to provide actions file feedback.
+
+ Once upon a time (~2003) there were scripts on the webserver
+ to make reporting action file feedback more convenient for the
+ user and the actual reports more useful for the developers.
+ They have been unusable for years and have thus been disabled,
+ but making the reporting mechanism available again would be a
+ good idea.
+
+140) Toggling Privoxy off currently also disables stuff that
+ probably shouldn't be affected (such as actions like
+ forward-override). Investigate and fix or document.
+
+142) Remove or update the "internal" pcre version.
+
+143) Add support for OpenBSD's pledge feature once it's stablelized.
+ This should be a lot less work then #124.
+
+146) Allow to save the internal client tag state to disk and
+ load it after restarts.
+
+147) Improve "Building from Source" section in the user manual.
+ A common problem seems to be that it's not obvious to non-technical
+ users how the listed dependencies can be installed on the commonly
+ used platforms. Adding a couple of examples should also be useful for
+ technical users (like Privoxy developers) who want to install or test
+ Privoxy on platforms they are not familiar with.
+
+148) Add a config directive to change the CGI_SITE_2_HOST
+ (default: config.privoxy.org).
+
+ If Privoxy is used as reverse proxy or intercepting proxy without
+ getting intercepted requests, error pages created from default templates
+ currently can result in client requests to config.privoxy.org on the
+ Internet which may not be desirable.
+
+150) Add blacklistd support.
+
+151) Let the dok-tidy target work cross-platform without introducing
+ a ton of white-space changes that hide the content changes.
+
+152) Fix CSS references in the website documentation.
+ For many pages p_doc.css is specified twice using different paths.
+ Usually at least one works, but not all of them do and the
+ duplicated requests are pointless even if they don't end up with
+ a 404.
+
+153) Catch SIGINT and use it to close the listen socket, serve
+ remaining connections and shut down. This would allow higher
+ uptime and make testing more convenient.
+
+154) Underline links in docs and cgi pages. More precisely,
+ don't mess with the browser defaults for link underlining.
+
+155) The sig_handler() shouldn't call log_error().
+ While it isn't known to cause actual problems in normal operation,
+ it's technically incorrect and causes crashes when running in
+ valgrind.
+
+156) Reject socks requests with an explicit error message similar
+ to the one used for ftp. Motivation:
+ https://lists.privoxy.org/pipermail/privoxy-users/2017-March/000195.html
+
+158) Use a single thread to wait for new requests on reused client connections.
+ Currently the thread that handles the first request on a connection
+ stays responsible for the client connect until it gets closed.
+ In case of lots of idle connections lots of waiting threads are used.
+ While it's conceivable that this ineffiency is irrelevant from a
+ performance point of view, using a single thread should reduce Privoxy's
+ memory footprint a bit which may be noticeable in case of multi-user setups
+ with hundreds of idle connections.
+
+161) Properly support requests with chunked transfer-encoding with https inspection.
+
+162) When https inspecting, delete generated keys and certificates if
+ the connection to the destination could not be established.
+ Makes silly DoS attacks slightly more complicated.
+
+163) Use subdirectories in the certificate-directory to lower the number
+ of files per directory.
+
+164) Evaluate switching from pcreposix(3) to pcre's native api
+ for URL matching which allows to compile the patterns once
+ at load-time.
+
+165) Add a max-connections-per-client directive.
+
+166) Figure out how to ship Windows binaries with external libraries
+ like pcre and MbedTLS. Required for #142. Somewhat related:
+ https://lists.privoxy.org/pipermail/privoxy-devel/2020-November/000400.html
+
+167) Set up a public Privoxy-Filter-Test instance.
+
+168) Add a privacy policy.
+
+169) Preserve all relevant copyright and license statements in binary
+ packages we distribute.
+
+170) Serve the ca-cert-file through the CGI interface so clients
+ can conveniently import it (insecurely).
+
+171) Create a "view page using Privoxy" website where users can input
+ an URL and get a screenshot of a browser fetching the URL
+ through Privoxy.
+
+172) Create a public git repository for Privoxy-Filter-Test.
+
+173) Document Privoxy's governance model.
+
+174) Let the Tor Onion Service for the privoxy website
+ serve gitweb and the git repository as well.
+
+175) Add more screenshots to the documentation and website.
+
+176) Find a new fiduciary sponsor as a replacement for Zwiebelfreunde e.V.,
+ so that we can continue to receive tax-deductible donations in Europe.
+
+177) Support https-inspection for intercepted requests.
+
+178) Warn on http://config.privoxy.org/client-tags if a Tag name
+ has't at least one matching action section.
+
+179) Add a add-server-header{} action to add headers to the response
+ sent to the client (including responses generated by Privoxy itself).
+
+180) Add support for GnuTLS.
+
+181) Allow to upgrade an http request to https behind the
+ client's back using a client-header filter.
+
+182) Before enforcing the client-header-order, check that the
+ client headers actually need sorting. Should reduce log
+ messages and memory allocations.
+
+183) Properly deal with proxy responses that arrive in multiple pieces
+ when https inspecting while using a forwarding proxy.
+
+184) Add support for wolfSSL. Work in progress, expected to be
+ committed after the 3.0.30 release.
+
+185) The mbedTLS and OpenSSL versions of generate_host_certificate()
+ should only be called when necessary and the check should be
+ done without holding the certificate mutex.
+
+186) Privoxy should handle "OPTIONS *" requests properly.
+
+187) There should be a convenient way to see the versions of
+ the libraries Privoxy is using.
+
+188) In the windows config.txt file, add the line
+ user-manual ./doc/user-manual/
+ right after
+ # Copyright ...
+ #
+
+189) Bring back binary packages for macOS, preferably for both Intel and M1.
+ The first step would be getting at least one build system, either
+ donated or bought with donations earmarked for this.
+ Interested donors: 0.
+
+190) The socks5 authentication code should send user name an password
+ seperately or we should increase the cbuf size to allow longer
+ user names and passwords.
+
+191) The cipher-list directive should be split into cipher-list-server
+ and cipher-list-client.
+
+192) The client TLS contexts should probably be shared among threads
+ to spend less time and memory loading the root certificates.
+
+##########################################################################
+
+Hosting wish list (relevant for #53)
+
+What we need:
+
+- Bug tracker
+- Mailinglists (Mailman with public archives preferred)
+- Webspace (on a Unix-like OS that works with the webserver targets
+ in GNUMakefile)
+- Git repositories
+- Commit mails (preferably with unified diffs)
+
+(Unsorted) details to look at when evaluating hosters:
+
+1. Preferably no third-party ads and trackers.
+ External images, CSS and JavaScript may count as trackers
+ but texts like "supported by company XYZ" may be acceptable.
+
+2. JavaScript should be optional or not used at all.
+
+3. Services we don't need shouldn't be enabled anyway.
+ (We currently don't use Web forums, wikis, surveys etc.)
+
+4. It would be preferable if the hoster didn't have a bad track
+ record as far as user experience, security and privacy are
+ concerned and if the terms of service are "reasonable" and
+ haven't changed too often in the past. Updates in the past
+ should have been improvements and not regressions.
+
+5. It would be preferable if most of the server administration
+ is done by a trusted third-party (or at least not a lot of work
+ for us).
+
+6. The server(s) should be located in a country with laws we can
+ understand and follow (or at least not unintentionally violate).
+
+7. A server location in a country with some kind of due process
+ and strong data protection laws (at least on paper) would be
+ preferable.
+
+8. Given that Privoxy is a free software project it would be
+ preferable if the hoster would use free software where possible.
+
+9. Migrating away from the hoster in the future without losing
+ any important data should be possible without writing web
+ scrapers first.