Archive for February, 2011

08 FebMozilla’s (alpha) Privacy Icons

At the end of 2010, I saw the “alpha release” of Mozilla’s privacy icons. As explained in that blog post, this was the culmination of efforts undertaken throughout the last year, including a workshop that was attended by some very smart folks.

In advising some students at UC Berkeley’s School of Information on their Masters Final Project, KnowPrivacy, I spent a good bit of time thinking about privacy policies and we even created our own set of “privacy icons” to reflect some of the features of the privacy policies analyzed. (See the KnowPrivacy profile for Google, for an example.) This experience taught us that online privacy is a HARD policy issue. Designing useful, comprehensible privacy icons that might actually get used is just one really hard part of a really hard problem.

I preface my remarks with all that in order to make clear that what follows is not intended as criticism, but feedback, which Mozilla has solicited all along the way.

Which Distinctions Matter?

A difficult problem facing anyone seeking to make privacy icons is that you have to decide which distinctions you are going to illustrate, typically based on what distinctions you think do (or should) matter to the audience for those privacy icons.

I disagree with three choices the Mozilla team made about which distinctions to illustrate with their privacy icons.

  1. The Mozilla (alpha) privacy icons do not distinguish between the types of data collected.
    • This is a mistake because most users don’t care if a site collects data on which web browser they used (and whether the site keeps such information forever) but many users do care if a site collects their credit card number (or health records or …) and intends to retain it.
  2. The Mozilla (alpha) privacy icons’ distinction between your data being “given” to “advertisers” or not is too coarse-grained.
    • The KnowPrivacy researchers found that many sites do not “give” information to anyone, but many popular websites allow third parties to place collection webbugs right there on the site’s home page. Privacy policies exploit this distinction to hide the fact that your information is leaking. While Mozilla’s explanation of this icon group seems to take this into account, there is no reason to expect that most users will understand this.
    • The KnowPrivacy researchers also found that most popular sites share with “affiliates”, some share with “contractors”, some share with “advertisers” and some share with third parties generally. The icon group only references “advertisers” and a finer-grained set of distinctions might encourage greater transparency about these different sorts of sharing.
  3. The Mozilla (alpha) privacy icons’ distinction between your data being sold or given away is not typically a distinction that users do (or should) care about.
    • Users just want to know who has or might get their data and don’t really care what the monetary terms of the deal were when their data was given/sold to another party.

Stylistically, one thing I really like in the alpha release is the length-of-time icons for indicating how long a user’s data is kept. However, the KnowPrivacy researchers found that most popular websites do not disclose the length of retention, and so one can assume that, at present, only the infinite icon would get much use. However, perhaps these retention icons would be a sort of public shaming that might encourage sites to select a data retention time period and to disclose it.

Finally, I don’t mean to suggest that the Mozilla team should have just adopted the KnowPrivacy icons and called it a day. The KnowPrivacy icons were intended for an audience visiting the KnowPrivacy website, i.e., a user that is engaged in comparing and contrasting the policies of the most-visited websites. Mozilla’s use case is different and almost certainly requires a different set of icons to serve their purposes. However, my points above are intended to suggest that even for their purposes, Mozilla should strive to capture a different set of distinctions in the beta release.

04 FebAdding Mailman to Postfix with Virtual Domains

I am a big fan of the cut-and-paste howtos provided at howtoforge.com.

I’ve used something like falko’s howto on Virtual Users And Domains With Postfix, Courier, MySQL And SquirrelMail (Ubuntu 10.10) in order to get a mail server with those features working on Debian Squeeze.

Then I wanted to add mailman in order to operate mailing lists.

The closest howto for achieving this is the one by Rich Brown, How to add Mailman mailing lists to Postfix under Ubuntu Linux when using virtual domains + virtual users.

I’m going to try to recount what I had to do to go from a working mail server with virtual users and domains (having completed a howtoforge.com howto) to get to that same setup to run mailman. Perhaps some of this was unnecessary, duplicative, or even wrong. But, the mailing lists are working now, so that’s something.

List domain preparation

If the domain that will host the lists is not already served by your setup, be sure you:

  • use phpmyadmin to create the domain example.com in the domains field. NOT lists.example.com!, and
  • add lists.example.com to your dns entry for example.com,

Mailman

As root:

# aptitude install mailman
# newlist mailman
# vi /etc/aliases

And add the following to /etc/aliases:

## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

# vi /etc/mailman/mm_cfg.py

and uncomment and/or appropriately edit the following lines:

DEFAULT_EMAIL_HOST = 'lists.example.com'
...
DEFAULT_URL_HOST   = 'lists.example.com'
...
MTA=None   # Misnomer, suppresses alias output on newlist
...
GLOBAL_PIPELINE.insert(1, 'SpamAssassin')

Apache2

create a new file: /etc/apache2/mods-available/mailman.conf that looks like this:

ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
ScriptAlias /cgi-bin/mailman/ /usr/lib/cgi-bin/mailman/

<Directory /usr/lib/cgi-bin/mailman/>
   AllowOverride None
   Options ExecCGI
   Order allow,deny
   Allow from all
</Directory>

Alias /pipermail/ /var/lib/mailman/archives/public/
<Directory /var/lib/mailman/archives/public>
   Options Indexes MultiViews FollowSymLinks
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

Alias /archives/ /var/lib/mailman/archives/public/
<Directory /var/lib/mailman/archives/public>
   Options Indexes MultiViews FollowSymLinks
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

Now add a symlink to this file so Apache will use your new Mailman aliases the next time it starts:

# cd /etc/apache2/mods-enabled
# ln -s /etc/apache2/mods-available/mailman.conf mailman.conf

Postfix

Create a new file, /etc/postfix/transport, which contains one line:

lists.example.com     mailman:

Then as root:

# cd /etc/postfix
# postmap transport

Finally edit /etc/postfix/main.cf – add these four lines to the end of the file:
relay_domains = lists.example.com
transport_maps = hash:/etc/postfix/transport
mailman_destination_recipient_limit = 1
unknown_local_recipient_reject_code = 550

Use phpmyadmin to add some aliases in the forwardings field:

mailman@example.com	mailman@lists.example.com
mailman-admin@example.com	mailman-admin@lists.example.com
mailman-bounces@example.com	mailman-bounces@lists.example.com
mailman-confirm@example.com	mailman-confirm@lists.example.com
mailman-join@example.com	mailman-join@lists.example.com
mailman-leave@example.com	mailman-leave@lists.example.com
mailman-owner@example.com	mailman-owner@lists.example.com
mailman-request@example.com	mailman-request@lists.example.com
mailman-subscribe@example.com	mailman-subscribe@lists.example.com
mailman-unsubscribe@example.com	mailman-unsubscribe@lists.example.com

Finishing up

# newaliases
# service apache2 restart
# postfix reload
# service mailman start

After some combination of the above and hopefully not forgetting anything–note my uncertainty there–mailing lists just started working! Go to: http://lists.example.com/mailman/admin/ and get started creating a test list to confirm everything is working.