[tor-project] The Tor Project Social Contract

Mike Perry mikeperry at torproject.org
Mon Aug 1 19:43:59 UTC 2016


Alison:
> Hello good people of tor-project@! I'm excited to present to you
> something that a number of us core members have been working on for some
> time now: the Tor Project Social Contract 1.0 [1]. Modeled after the
> Debian Social Contract [2], the Tor Project Social Contract is a set of
> promises to our community about what Tor stands for and why we create it.
> 
> I'm sharing it with all of you today so that we can work on
> ratification. I think that the best way to do this is as follows:
> 
> By 6 August at 00:00 UTC, please respond to me or to the list if you
> accept or object to this social contract so that we can ratify this
> through rough consensus [3].
> 
> If objecting: Please be specific about your objections so that we can
> discuss changes as needed. If you respond directly to me, I will assume
> that you don't want your name shared with the group, but please specify
> if you don't want your comments shared either. NB: THIS IS NOT AN
> INVITATION TO EDIT BY COMMITTEE. I'm interested in feedback like "this
> does not represent the Tor that I know" not "I'd like this sentence
> reworded". Please also be kind, because this was written by humans.

I hate to be late to the party, and I hate to start a libre/free/open
flamewar, but I am concerned about the specific language "free of cost"
with respect to our tools in Point #3.

In my opinion, dragging statements about money/revenue into the social
contract is limiting and may cause unnecessary divisions in the
community. Here are three examples to consider:

1. If a member of the Tor community (ex: the Guardian Project, an
independent for-profit entity, or perhaps a for-profit subsidiary of Tor
Project Inc) creates a Tor-enabled Android phone, a Tor-enabled
Chromebook, a Tor Router, or similar, and sells pre-installed versions
of that hardware for fundraising purposes or directly for profit, is
that a violation of Point #3? What if the implementations are open
source? What if they are not? What if some components are not (like
video drivers, or similar non-security-critical components)?

2. If an alternate bridge provider created a BridgeDB instance that
handed out bridges in exchange for money/bitcoin, would that be in
violation of the "free to access" standard? What if they upstreamed
their modifications and open sourced their implementation? What if they
didn't?

3. OnionBrowser costs $1 in the iOS App Store, but it is open source,
and people are free to build their own versions. Would Mike Tigas be in
violation of the social contract for doing this? For an extra wrinkle,
OnionBrowser was not initially open source. Does that make a difference?
(I think it does.)


In my opinion, all of the above would be cleaner to answer if we chose
some wording that did not invoke any monetary interpretation in our use
of "free", or even the word "free" at all. I see nothing wrong with paid
versions of Tor tools, paid hardware, or paid access, so long as the
implementations of security-critical components are open source and
auditable. Maybe others disagree?


Here's an attempt to reword to capture my thinking:

  3. Our tools are universally available to access, use, adapt, and distribute
  
  The more diverse our users, the less simply being a user of Tor implies
  about any user, so we aim to create tools that anyone can access and
  use. We do not restrict access to our tools unless it is for the
  security of all users, and we design, build, and deploy our tools
  without collecting identifiable information about our users. We expect
  the code and research we publish to be improved by many different
  people, and that is only possible if everyone has the ability to use,
  copy, modify, and redistribute our tools.


Otherwise, I'm on board with the rest of the social contract. Nice work
Alison, et al!

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20160801/e880ab00/attachment.sig>


More information about the tor-project mailing list