[tor-relays-universities] Tor on Campus

Nik nskinkel at iastate.edu
Sat Sep 20 04:41:24 UTC 2014


> One conversation with parties to an edu yielded that they had no
> real working process for evaluating and accepting tertiary projects.

<snip>

> they had no particular process in place to execute on that, so it
> didn't happen. And without process, examples of existing tertiary
> (arbitrary) projects were denied as replication models for yours.

A group of friends and I have been working with the IT department at our
university to get an exit set up, and one of the ways we've gotten
around this problem is by forming an official, recognized student
organization.

Student orgs (at least here) are able to request resources from the
university (e.g. rackspace/bandwidth), funds from the Government of the
Student Body, etc., so there's a somewhat established channel to go
through the process.  The IT folks here have actually been pretty great
so far (if a little slow moving), although we have some personal
connections with them so it makes things a bit smoother.

This is just our personal experience, so take it with a grain of salt,
but we've found there are 3 major things the IT bureaucracy wants to
see, and in conversations with them it's come up that individuals trying
to do things like run a Tor node in the past have been shut down for
lacking (at least) one of these things:

1) Accountability - they want someone/some group who will step up to
handle things like DMCA requests, abuse complaints, etc.  Individual
undergrads don't cut it here because they aren't around long-term and
tend to lose interest after a while anyway.  Ideally, a long-term
university employee should put their name down as a contact/responsible
party (even if it's not actually them responding to issues), but perhaps
a student group could step up here too if they're firmly established.

2) Clear Admin/Security Policy - they want a well-defined security
policy for maintaining the box long-term and limiting abuse potential.
Less so, it seems, to actually verify that the box is secure, and more
to just show various administrators to say "hey, we made sure they
followed best practices - if something happens it's not our fault."
Additionally, they want to ensure the university isn't somehow made
liable for the activities of Tor users (e.g. by providing access to
people around the world to journal subscriptions that are only supposed
to be available to students).

3) Precedent - one of the most important issues they've brought up.
They want to see that an exit node has been run successfully at other
universities with minimal headaches.  They're most interested in the
setups that have worked for others, specific exit-policies and
abuse-response procedures primarily.

This all basically boils down to "Don't make the IT people's lives more
difficult."

A couple resources that I think could really help/streamline this
process for other students in the future are:

(A) A list of currently active exits at universities, filterable by
country at least (laws/regulations are different).

It would be really great to have some sections here for each university
listing like: the exit policy (or policies), the way they get around
problems like journal subscriptions, how they handle abuse complaints,
how long the exit has been running, etc.

(B) Some suggestions for helping students/student groups find solutions
to common problems.

Not sure how to limit access to subscription databases?  Try getting an
IP outside the university's netblock or making friends with a librarian
who can make sure you always have an updated subscription list.  IT
people worried about a flood of abuse complaints?  Here's an exit policy
that's been shown to minimize problems.

I know some/most of this information exists in various places already,
but it would be extremely helpful to aggregate it in a nice format for
both students working to setup nodes as well as a place to point
curious/skeptical administrators.

This: https://www.eff.org/torchallenge/tor-on-campus.html

is somewhat close to what I'm describing, but, critically, it's lacking
a searchable/filterable listing of current university exits.  And while
it does have a "Tactics for Addressing Potential Concerns" section that
lists possible *solutions* to common problems, I think it might be good
to have like a "Roadblocks" section or something that lists potential
*problems* themselves.

A lot of the information is there, it seems, just not a clear mapping of
problem -> solution.

Nik

On 09/19/2014 06:26 PM, grarpamp wrote:
> On Fri, Sep 19, 2014 at 6:13 PM, April Glaser <april at eff.org> wrote:
>> Also let us know if you're currently in process and
>> facing road blocks.
> 
> One conversation with parties to an edu yielded that they had no
> real working process for evaluating and accepting tertiary projects.
> 
> For example, the process did exist for faculty actively engaged in
> bonafide research pursuant to paper production, licensing, etc. And
> for students actively enrolled in a class which graded academic
> projects for which writing code or learning sysadmin might be their
> project.
> 
> However if you were merely a student in the dorms, a janitor, office
> or IT worker, faculty, or anyone else simply wishing to run a node
> outside of the above business/academic progress, even if doing so
> would earn public recognition and carry little risk or cost...
> 
> they had no particular process in place to execute on that, so it
> didn't happen. And without process, examples of existing tertiary
> (arbitrary) projects were denied as replication models for yours.
> 
> EFF/TOR might be able to assist those in that situation by providing
> a page on forming a framework, and what that framework might look
> like.
> _______________________________________________
> tor-relays-universities mailing list
> tor-relays-universities at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays-universities
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays-universities/attachments/20140919/bd9c787b/attachment.sig>


More information about the tor-relays-universities mailing list