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

[tor]

In addition I came across these, as I quite often have acted under color 
of law when investigating computer intrusions/assisting law enforcement 
investigations. these are also very interesting

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)(i)

and 3a


    (i) It shall not be unlawful under this chapter for a person acting 
under color of law to intercept the wire or electronic communications of 
a computer trespasser transmitted to, through, or from the protected 
computer, if--
        (I) the owner or operator of the protected computer authorizes 
    the interception of the computer trespasser's communications on the 
    protected computer;
        (II) the person acting under color of law is lawfully engaged in 
    an investigation;
        (III) the person acting under color of law has reasonable 
    grounds to believe that the contents of the computer trespasser's 
    communications will be relevant to the investigation; and
        (IV) such interception does not acquire communications other 
    than those transmitted to or from the computer trespasser.

    (3)(a) Except as provided in paragraph (b) of this subsection, a 
person or entity providing an electronic communication service to the 
public shall not intentionally divulge the contents of any communication 
(other than one to such person or entity, or an agent thereof) while in 
transmission on that service to any person or entity other than an 
addressee or intended recipient of such communication or an agent of 
such addressee or intended recipient.
    (b) A person or entity providing electronic communication service to 
the public may divulge the contents of any such communication--
        (i) as otherwise authorized in section 2511(2)(a) or 2517 of 
    this title;
        (ii) with the lawful consent of the originator or any addressee 
    or intended recipient of such communication;
        (iii) to a person employed or authorized, or whose facilities 
    are used, to forward such communication to its destination; or
        (iv) which were inadvertently obtained by the service provider 
    and which appear to pertain to the commission of a crime, if such 
    divulgence is made to a law enforcement agency.


note item iv


      again comment is invited from REAL EFF Lawyers as we are talking about the ECPA now and this is 
actually what the text of the law says.

   a tor operator






tor wrote:

> 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.
>