[tor-relays-universities] (FWD) Higher education act

[Richard Johnson]

On Tue, Mar 12, 2013 at 06:43:42PM -0400, Wendy Seltzer wrote:
> For my research and ongoing conversations in Washington, I'm very
> interested to know about others who have heard this justification for
> network-restriction.

We've considered HEOA requirements, though the act doesn't directly apply
to us as written (we have no students), only in spirit.  We didn't re-
engineer or add restrictions to our network, but doing so was suggested.

The HEOA does apply directly to most of our USA-based member or affiliate
institutions, as they are degree-granting universities with graduate
programs in atmospheric, oceanic and related sciences (e.g., Harvard, Yale,
Univ. of California, Berkeley), and hence have students. 

Our member institutions do send us student and faculty visitors, plus a
large number of post-doctoral researchers, some of whom become staff here,
or researchers at other member institutions.  For that reason, I'm
personally concerned with the HEOA, in spirit.

The HEOA also applies to many of our peer institutions who are members of
the Front Range GigaPOP (FRGP, www.frgp.net).

The discussions I'm aware of within the FRGP community necessarily left
HEOA compliance measures to each individual institution, as each has a
different population and culture, and some are not subject to the act.  The
FRGP provides transit, not filtering.  However, it does in effect assist
with efficiently providing paid content to consumers at member institutions
via co-located CDN nodes (e.g., Akamai) and service caches (e.g., Netflix).
This is done for maximizing upstream bandwidth efficiency, and not for HEOA
compliance, though I would be surprised if it escaped any affected members'
notice that it can also be a win for "alternatives" language.

It was initially suggested by some staff (when the bill was being debated)
that UCAR might have to redesign some of our network to follow the HEOA.
However, we figured out that our existing copyright policies and education
efforts, as well as our technical protections against outside network
attack, would continue to prevent the problems that the HEOA was intended
to address.  This has proven to be the case in practice, with only 2 DMCA
takedown notices that might might have been legitimate (but were false
alarms) received among the thousands of more mundanely erroneous DMCA
takedown notices delivered or misdelivered.

Note that this HEOA consideration has not yet involved our Tor exits.
Those are not used for exiting by our local staff or visitors, per design
of the protocol.  Also, as we know, Tor is poor for file sharing both in
terms of speed and easy de-anonymization of the sharer.  Further, we do not
monitor Tor network traffic, per reasonable and necessary Tor network rules
for preserving user anonymity.

The critical and significant non-infringing uses of Tor for intel
gathering, malware analysis, censorship evasion, safety/life preservation,
and more general research mean it would be a major re-engineering step, and
loss of essential functionality, to restrict Tor nodes.  I don't think such
restrictions would pass muster here for HEOA, especially as I believe Tor
already contains in its nature effective combating of unauthorized
distribution via file sharing (e.g., inherent bandwidth shaping, and no
scrubbing of in-packet leaks of origin IP addresses from file-sharing
software).

All that said, after reading the EPO0938.pdf (thanks, Thomas), I now have a
new action item for work.  I've got to see about expanding our staff and
visitor education regarding fair use.  UCAR's Open Sky initiative [1] is a
good start on the producer and archivist end, but I think we need more
scientists explicitly aware of fair use from other sources.

In summary, we didn't re-engineer or additionally restrict our network,
though we discussed the matter and determined our existing technical
measures and education efforts were effective for satisfying the spirit of
the HEOA.  Restricting/re-engineering Tor use for HEOA probably wouldn't
fly here, as it could be seen as overkill on top of a protocol that's
already technically and naturally ill-suited for file sharing.


Richard

[1] https://opensky.library.ucar.edu/ (I greatly appreciate our librarians.)