Privacy Patches and Packages

Privacy patches and custom Debian packages allow a system administrator to retain less data

Introduction

These patches and custom debian packages allow a system administrator to retain less data. Typically, it is not possible to control what data is retained, logged, and distributed with various internet services. By allowing you to retain less data, these patches increase users’ privacy and decrease the liability of the service provider.

Data retention has become a hot legal topic for ISPs and other Online Service Providers (OSPs). There are many instances where it is preferable to keep less information on users than is collected by default on many systems. In the United States, there is currently no requirement to retain data on users of a server, but you may be required to provide all data on a user which you have retained. OSPs can protect themselves from legal hassles and added work by choosing what data they wish to retain. OSPs can protect themselves from legal hassles and added work by choosing what data they wish to retain.

Different types of services

Different services require you to take different actions to add an anonymization/privacy layer. What action you take depends what services you are providing, and what your policy perspective is.

Note: We do not provide any techniques for writing data to disk, and then scrubbing it later. This technique is dangerous because the window between writing that data to disk, and then scrubbing it is one where you are taking a significant risk with your user’s privacy.

System Logging

Here are patches and details for how to configure various system loggers (syslog-ng, dsyslog, etc.) so that they will strip out personally identifying information before they are written to disk. This allows you centralized, fine-grained control over all system logging. Using this technique is one of the most effective, broad strokes that you can take to anonymize many disparate parts of your system all at once.

Mail

In the mail section, we provide both patches as well as configuration options for Postfix and Qmail to allow authenticated SMTP without including the user’s home IP address in outgoing mail, as well as for Postgrey to add the capability to store the IPs and emails in the greylisting database using a one-way SHA-1 hash function instead of clear-text tuples.

Apache

Information about how to keep Apache from logging IP addresses (it is harder than you might think).

Webmail

Patches to IMP and Squirrelmail to prevent them from including the user’s home address in outgoing mail. As well as a security plugin for Squirrelmail.

Mailman

How to anonymize Mailman a bit.

Postgrey

A way to enhance postgrey to store the IPs and emails in the greylisting database using a one-way SHA1 hash function, instead of in clear-text. This will defeat straight-forward attempts to retrieve mail user behaviors. The goal is to give the system administrator the means to implement their site-logging policies by allowing them easier control over the privacy behavior of what information postgrey gathers.

See also / References

 

This looks like the old page at riseuplabs.org/privacy
but it is not public. What is the canonical location?

 
 

i’ve been trying to move the privacy pages from bamboo to crabgrass. the reason the ones in crabgrass are private is because the move isn’t finished yet.

 
 

I know people think i’m a runit proselytizer, but this is another situation where having a more sensible system process management makes a big difference.

By default with runit, daemons are encouraged to log to stdout or stderr. The supervising program (runsv) runs the daemon concurrently with a separate logging process. The logging process’s stdin is hooked to the daemon’s stdout/stderr, and it’s the logging process’s job to decide what gets written to disk.

You can then make this sort of filtering decision (e.g. an pipelined “sed” script that scrubs IP addresses if that’s what you like) trivially in the logging process, and it works for all daemons — no need for patches.

 
   

This page is public now, its intended to serve as the redirect for the older pages at: dev.riseup.net/privacy