The legal basis for Service monitoring Title 18 Section 2511.2.a.i Re: Why TOR Operators SHOULD always sniff their exit traffic...

tor tor at algae-world.com
Fri Jun 10 02:30:14 UTC 2005


Hi All,


BTW Chris... you may wish to examine with your EFF Attorney the 
following section of USC Code Title 18

     http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=browse_usc&docid=Cite:+18USC2511

to wit:

TITLE 18--CRIMES AND CRIMINAL PROCEDURE
 
                             PART I--CRIMES
 
    CHAPTER 119--WIRE AND ELECTRONIC COMMUNICATIONS INTERCEPTION AND 
                   INTERCEPTION OF ORAL COMMUNICATIONS
 
Sec. 2511. Interception and disclosure of wire, oral, or 
        electronic communications prohibited

    (2)(a)(i) It shall not be unlawful under this chapter for an 
operator of a switchboard, or an officer, employee, or agent of a 
provider of wire or electronic communication service, whose facilities 
are used in the transmission of a wire or electronic communication, to 
intercept, disclose, or use that communication in the normal course of 
his employment while engaged in any activity which is a necessary 
incident to the rendition of his service or to the protection of the 
rights or property of the provider of that service, except that a 
provider of wire communication service to the public shall not utilize 
service observing or random monitoring except for mechanical or service 
quality control checks.

Note the phrase "to the protection of the rights or property of the provider of that service".
Note the prohibition of service observing/Random Monitoring applies to wire communication services only
(IE telephone companies). If current case law contradicts this please feel free to inform us all via the 
with specific cases etc...

please chris have the EFF lawyers comment on this aspect of ECPA. I am sure all us on the list would 
indeed be fascinated.



    a tor operator
 



Chris Palmer wrote:

> Parker Thompson wrote:
>
> >I'm not so interested in specific legal advice, more a high level
> >discussion of when it is good to be a bad guy, and when you're being
> >bad for the sake of being good what are the ethical considerations
> >and, with respect to Tor (it'll differ case to case) legal
> >implications of doing so.
>
> >I would think this would be a perfect discussion to have in the
> >context of Tor, and perhaps the kind of thing the EFF could turn into
> >a compelling policy paper to guide the development of this and other
> >projects.  Further, I see this as far preferable to letting operators
> >develop their own best practices on an ad-hoc basis.
>
>
> I understand the need, and I'll fly it past our lawyers to see what they
> think about drafting such a policy paper. They are unlikely to make
> strong, specific, forward-looking legal statements, of course.
>
> I can tell you what I do, which I regard as reasonably safe and polite.
>
> I run three Tor servers: one at EFF (confidence), one on a machine some
> friends and I share (explosivenoodle), and one on my home DSL line
> (livingcolour). confidence and explosivenoodle I run in middleman mode,
> to minimize annoyance and potential liability for my employer and
> friends (respectively). (EFF is considering running an exit server, but
> we aren't yet.) livingcolour uses the default exit policy. All three
> servers are rate-limited to about 20Kb/s because bandwidth is either
> donated and I want to be nice (explosivenoodle), or limited (confidence
> and livingcolour). I don't sniff traffic on any of these three hosts,
> and I log at warn level, using debug level only for limited times when I
> actually am trying to debug something (rarely). All three machines are
> kept up-to-date and run only services I actually use.
>
> I don't commit abuse through Tor when I use it. That's easy -- "Oops, I
> didn't troll on IRC again!"
>
> I sometimes drive around in the Tor source tree for fun and learning,
> but I haven't found any security bugs. If I did, I would simply tell
> Roger and Nick. I have reported a few security-irrelevant bugs (and, I
> sheepishly admit, non-bugs) to R and N and they have fixed them fast.
> There was once a problem with bad interaction between two configuration
> directives, for example, which caused Tor not to start. Nick fixed it in
> minutes.
>
> Hence, for basic operation and examination, the existing norms of the
> competent sys admin and white hat security researcher communities apply.
>
> As for passing "bad" traffic, so far I haven't heard from my ISP about
> any problems with my exit node. Maybe I'm just lucky. There are various
> types of complaints, and different responses are called for in different
> circumstances. Get legal counsel, possibly the EFF. See also the Legal
> FAQ and our DMCA response template
> (http://tor.eff.org/eff/tor-dmca-response.html). Everyone has different
> responses to complaints, resulting from the specifics of their
> situation, their beliefs and temperaments, the nature of the complaint,
> their relationship with the complainant and with their connectivity
> provider, various jursidictional issues, and so on. It's hard to make
> any general a priori statements about what to do, other than "Call
> EFF!". That's obviously what I would do. :)
>
> I don't know if that helps you or answers your question. I'll state
> again that the non-dangerous techniques I mentioned in my previous email
> have proven helpful in finding bugs in other software products. Roger
> and Nick welcome substantive bug reports, and they take security very
> seriously.



More information about the tor-talk mailing list