- tor-relays - lists.torproject.org

Question about responding to abuse request
by Patrick ZAJDA 05 Jul '15

05 Jul '15

Hi all, I run a Tor exit node, and I received an abuse complain from Webiron. In this mail, I can read the following: "If you run a VPN, anonymizer service (like a TOR exit or proxy node), or business intelligence not contracted with the site owner, then we request that the targeted range be blocked from your service. If it is being blocked, then it's at the right and choice of our clients to refuse access." So if I understand correctly, they ask me to block the targeted range they give me in this report. I know I can block this IP range by adding it to my exit policy, but I would like to know how others exit node operators manage these type of requests, because I ask myself if it is not against tor philosophy to block access to a specific network to Tor users. Thanks all in advance for your answers. Best regards, -- Patrick ZAJDA

5 4

Running a Relay behind a NAT (was Re: unflagged BAD EXIT nodes)
by teor 05 Jul '15

05 Jul '15

> Date: Sat, 4 Jul 2015 19:34:45 -0400 > From: Ben Serebin <ben(a)reefsolutions.com> > Subject: Re: [tor-relays] unflagged BAD EXIT nodes > > ?I'll hijack the response.... I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are: > > - Windows installer (omg, Windows, the evil one which if you really want greater adoption is the answer! Oh smokes, someone said it! I agree that relay installers, particularly for non-Linux platforms, would help increase Tor's platform diversity. But platform diversity isn't a large part of Tor's threat model, as its impact is mainly felt through vulnerabilities shared by an entire platform. Currently, it looks like 90% of the Tor relays are Linux, by count of relays. (I believe the weighted bandwidth statistic is much higher than 90%.) https://metrics.torproject.org/platforms.html One suggestion I've heard, but that isn't ideal, is to download the Tor Browser Bundle, and modify the torrc in it to run a relay. That said, a relay operator really needs to know how to download, install, and configure a service on a secured server. So that's one reason a one-click installer is a bad idea. > - change the architecture so running behind nat works (this is probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane! Tor relays run quite fine behind a NAT, as long as the NAT box handles the number of connections which tor makes. There's even src/tools/tor-fw-helper, which supports NAT-PMP and UPnP. It can be configured via the torrc option: PortForwarding 1 Or, you can configure your NAT box to forward ports yourself. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 1

unflagged BAD EXIT nodes
by starlight.2015q2＠binnacle.cx 05 Jul '15

05 Jul '15

Could someone comment on why 15 exit nodes discovered to be sniffing and abusing login credentials have not been marked with the BAD EXIT flag? The research appears to be legitimate, involved a good deal of effort, and seems credible: https://chloe.re/2015/06/20/a-month-with-badonions/ was blogged by Sophos, also credible https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-tors-exit-nodes/ Is there an issue of trust w/r/t this security researcher? An issue of methodology and/or reproducibility? A shortage of resources to follow up? An investigation attempting to identify the operators? The researcher writes that they received a polite reply from and was summarily ignored with no further comment. AND the exits continue to steal and abuse credentials. If true this would be contrary to the inclusiveness generally exhibited by the Tor Project. IMO a likely password-stealing exit should be marked-first, questions asked later. If some kind of mix-up or mistake has occurred, a good operator should readily be able to defend themselves and not feel ruffled for it.

7 11

Re: [tor-relays] unflagged BAD EXIT nodes
by starlight.2015q2＠binnacle.cx 04 Jul '15

04 Jul '15

At 10:04 7/4/2015 +0200, nusenu wrote: >I find it more worrying that we do not "hear" >about the 'more serious attacks' that keep >them busy and don't allow them to look into >i.e. 'AviatoChortler' (even after a few >weeks). That might mean that there is a >constant stream of 'more serious attacks' >(without information I can only guess). Here is one where 70 bad exits were rewriting an .onion address on a clearnet portal and sending a Tor email service's users to an evil onion clone: https://lists.torproject.org/pipermail/tor-talk/2015-April/037549.html I can see the argument for ignoring the near-zero-ranked exits (as they will virtually never be used) and the massive BW password stealer (due to the value of the bandwidth and the fact that HTTPS is immune to passive sniffing). But am concerned Chloe apparently received mute indifference as her contribution to the project is significant.

1 0

Re: [tor-relays] Simplifying ExoneraTor
by Magnus Hedemark 04 Jul '15

04 Jul '15

tor(a)dserrano5.es thus spoke: > Results: do we really need the "Exit: yes" column? Seems pretty redundant to > me. How so? All exits are relays, but not all relays are exits. And if a relay is only configured as an exit for part of the time, that's a potentially important part of the historic record. Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland

2 1

de-centralised bad exit list files - a bad and/or naive idea ?
by Toralf Förster 04 Jul '15

04 Jul '15

Reading "[tor-relays] unflagged BAD EXIT nodes" /me wonders, such a feature would makes sense. Technically this could yield to a ./torrc.d config directory, where tor users could store the (regular updated) list/s they do trusts. -- Toralf, pgp key: 872AE508 0076E94E

3 2

turned on statistics
by starlight.2015q2＠binnacle.cx 01 Jul '15

01 Jul '15

It looked interesting so I turned on EntryStatistics 1 ConnDirectionStatistics 1 HiddenServiceStatistics 1 in addition to the default DirReqStatistics 1 and the output is indeed interesting. Also have CellStatistics 1 though this information does not seem to be published in the ExtraInfo digest. Any reason why having any of these enabled might be a bad idea? Running 0.2.6.9.

1 0

How to create HSDir on a private network
by Ceysun Sucu 01 Jul '15

01 Jul '15

Hi, I'm currently trying to simulate a tor network on shadow to test out some properties of hidden service's, i was wondering how could i create a hidden service directory or if someone could point towards an example configuration. Thanks, C,Sucu

3 2

Tor handshaking
by Adrian Soh 30 Jun '15

30 Jun '15

My ISP slows handshaking (circuit initialization) severely. Are there Torrc settings or changes to Orbot (Android) that I could use?

2 1

Re: [tor-relays] A bridge too far
by jchase 29 Jun '15

29 Jun '15

Thanks, isis, for your answer. I restarted my bridge without the flags and it's been running 7 days and still no stable flag back. Any experiments you can suggest? -J Chase > jchase transcribed 0.8K bytes: >> Hello, >> Can anybody help me figure out why my bridge has stopped showing the >> flags fast, running and stable? Especially stable, I would love to get >> that flag back. I run two bridges, on two different Rasp Pi's, the one >> with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E16499 . >> The other with a globe fingerprint of >> 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . The first bridge runs with >> obfs 3 & 4 on a Pi 2. It seems I lost the stable flag around the time I >> got obfs 4 up and running. The second bridge runs only with obfs 3 on an >> older Pi. >> I've read that the stable flag is quite handy. Any ideas about how I can >> get it back? >> Greetings, >> J Chase > > Hi J, > > Your bridge B08284109C72C81ACF5866A17A4CC64CE3E16499 appears to have a current > uptime of about 50 hours, and to have the Stable flag, according to > dir-spec.txt, [0] it must have: > > "Stable" -- A router is 'Stable' if it is active, and either its Weighted > MTBF is at least the median for known active routers or its Weighted MTBF > corresponds to at least 7 days. > > Meaning that you probably just need to let the bridge run for a few more days, > and it'll get its Stable flag back. > > Also, for what it's worth, BridgeDB will still distribute your bridge, even if > it doesn't have the Stable flag. The only required flag for your bridge to > get distributed is the Running flag. However, you are correct that having the > Stable flag is useful, because BridgeDB, when distributing some bridges to a > user, will try pretty hard to make sure that at least one of the bridges has > the Stable flag. So, with the Stable flag, you've got a better chance of > being distributed to clients more often, but it's not strictly necessary to > have it, especially for a bridge like yours with small bandwidth and CPU. > > [0]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=26929b8c5554… >

1 0

Re: [tor-relays] More consensus weight problems
by Aaron Gibson 29 Jun '15

29 Jun '15

On 2015-06-29 17:51, Speak Freely wrote: > Hello, > > First of all, I love Tor. I love Tor Browser, and I love running > relays. > > When the problems are solved, I will most likely spin up more relays. > > I'm leaving my fastest relay running, as a method of checking the > status > for myself. The rest have already started to expire, and within the > next > week or so most of the other ones will have expired as well. > > I'm going to try tor-dev-alpha 2.7.1 and change fingerprints, as per a > suggestion from s7r, seeing as how I have nothing to lose. > > I just wish the bwauths could scan relays based off previous relative > consensus weights... If this particular relay was at 27000, it should > be > higher on the list to check compared to another one I have that is at > 487. My one relay was blazing fast with thousands of connections, my Well, relays are ranked by capacity, and split over several scanner processes - they do get measured against their relative peers. But it seems that, when they fall out of the measurement process ('Unmeasured') they must start again at the beginning. This is expected because all relays start Unmeasured, and gradually increase their position in the consensus (per relative capacity), in order to dampen sudden changes and limit sybil attacks by requiring relays to stick around for a while, increasing the cost to an adversary. It likely should not be the case that historically long running relays should start at the bottom if they are unmeasured for a short period of time. We are in the process of testing increasing the number of scanner and accompanying tor instances from 4 to 9 (double, plus one for currently unmeasured relays) in order to decrease the amount of time each fraction of the network takes to measure and ensure that new relays or unmeasured relays are measured often. There are additional patches that introduce extra exits into the slice of relays, if there are no suitable exits to measure with. This likely won't address the above behavior, but we hope it will reduce the number of relays that go missing. Currently we seem to have mixed results, with one Bandwidth Authority operator claiming minimal (50) unmeasured relays, and another claiming ~600 mixed relays. These numbers are not directly comparable because they were not sampled at the same time, and may not be representative of typical behavior - it's a little too soon to tell. It's a bit tricky to both test these changes, on the live tor network, demonstrate that they produce sane results, and convince the directory authority operators and partner bandwidth authority operators to upgrade - nor do we want to do that all at once - gradual change is better. So, the goal is to produce results that will convince operators they should update, improve the situation for relay operators, and then start looking at longer term solutions for the measurement problem that are more maintainable and scalable in the long run. > other is painfully useless with dozens, but my fastest one lost its > consensus while the slowest one kept it's consensus. It just seems > silly. That being said, I don't know how/if the bwauths scan in any > order or just willy-nilly, (that's not entirely true, I know it's > segmented to some degree as I recall reading a blog post about how it's > chopped up) but... I'd be much less upset if my best relays worked and > my worst relays didn't. More complaining... bleh. > I hope to have a testable hypothesis as to why your faster relays suffer(ed) more than the slower relays - it could be that the fraction of network by capacity allocated to a particular scanner is not well balanced, and that fraction is taking significantly longer to measure. In order to evaluate that statement I need to understand the common characteristics of relays that become unmeasured/lose rank and see if they are from a similar segment of the network, and whether or not that segment of the network takes longer to measure than other segments. Another hypothesis is that your relays are on the boundary between two segments, and that a transition between scanner instances causes enough missed measurements to drop your relays. It would be helpful to know what rank the last good measurement your or other relays had before becoming unmeasured. It will require some cooperation with the existing deployed Bandwidth Authorities, in order to learn what their current scan times are - I will be writing some simple scripts to scrape these results so that we can collect and publish some useful heuristics about the scanner processes to better try and debug this problem. > > One thing I would like to point out though... it appears... These > problems have at least a casual relationship with MyFamily. > > One group of MyFamily is completely done - all of them stuck at 20. > Another group of MyFamily is working happily. > I've been doing some tests over the past few months trying to > understand > why I keep having problems, and one thing has consistently popped up... > MyFamily. That is very interesting, because MyFamily should have nothing to do with the scanner process at all - I'll need to think about this some more. > > As one of MyFamily lost consensus, another family gained consensus back > on or around the same time. > > Yes, especially nusenu, I know I'm supposed to have it all configured > to > be under 1 MyFamily... But in a way I'm glad I didn't, as the casual > relationship I see really could only be seen having done what I did. > > I say casual because I have no proof of causation. But... it is > interesting. If no one else has experienced similar problems, then I'd > chock it up to a completely unexpected unrelated set of mysterious > circumstances that should not have happened for which there is no > explanation. > > Aaron, if there is anything I can do to help you please let me know. If anything that I said above sparks a thought, please let me know :) > > > So in conclusion, I'm not done, I'm just not happy. > > This was supposed to be a short email, oops. > > > Matt > Speak Freely

1 0

default value (after reboot ) of controller.get_server_descriptor.uptime changed ?
by Toralf Förster 28 Jun '15

28 Jun '15

I do wonder, why a python script [1], lines 22 and 113, nowadays returns "00:00:00" for the uptime of my exit relay, when the system was rebooted, whereas in former times '00:01:01' (= 61 sec) was returned. FWIW the only local change before reboot here was to switch from Gentoo hardened kernel 4.0.6 to 4.0.6-r1. [1] http://www.zwiebeltoralf.de/pub/info.py -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E

2 1

be in time or not to be in time ?
by Toralf Förster 28 Jun '15

28 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hhm, found this in the log: Jun 28 03:58:37.000 [warn] Our clock is 1 minutes, 23 seconds behind the time published in the consensus network status document (2015-06-28 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! NTP runs fine at this exit relay since months, and I found nothing in the log which would tell me that sth was wrong with the time. Any hints / explanations ? - -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWPuw0ACgkQxOrN3gB26U71+wD+PIH6JSVqR8SJ/43wwDZKNibH UdvUWwDG4eQQ5kn/3N4A/AydwluUvBMXXSy7fh+Zphg1dCUF+zq7jKmxzRYcAZ2A =bnzu -----END PGP SIGNATURE-----

2 2

More consensus weight problems
by Speak Freely 27 Jun '15

27 Jun '15

Just thought I'd throw it out there. About 5 days ago I setup a new relay - it's consensus weight is still at 20. Then, I noticed a relay I've been running for about a month all of sudden lost all of it's consensus weight. It was ~17000, now at 20. It's uptime is 25 days, and has downloaded 4.8TB and updated 5.0TB in that time. Normally, when I have a consensus weight of 20, I also see a measured speed in arm of 160b/s. However, my month old relay's measured speed is showing 136.7Kb/s. This relay was averaging 15-25Mbit/s up until today, but now jumps between 600Kbit - 8Mbit, but mainly between 800Kbit-2Mbit. My other relays with the same provider have not experienced this, nor have my relays with different providers. Just this one. The interesting one: https://atlas.torproject.org/#details/D60B02A13F5D9CAFD6EC27A5332C5FEF5B769… Matt Speak Freely

4 6

circuit_unlink_all_from_channel
by Logforme 27 Jun '15

27 Jun '15

FYI I run the relay 855BC2DABE24C861CD887DB9B2E950424B49FC34. Today I found a message in the log file I have not seen before: Jun 26 18:05:20.000 [warn] circuit_unlink_all_from_channel(): Bug: Circuit on detached list which I had no reason to mark Relay continues to run fine with 30 days uptime.

2 1

Re: [tor-relays] No Exit flag on Exit node
by spiros_spiros＠freemail.gr 25 Jun '15

25 Jun '15

Aha thank you, so simple! I will make the changes. Spiros Στις 25 Ιούνη, 2015, στις 19:18, ο Tom van der Woerdt <info(a)tvdw.eu> έγραψε: Hi, You need two of the ports [80,443,6667] allowed to get the Exit flag. Of these, your exit configuration only allows 80. Tom spiros_spiros(a)freemail.gr schreef op 25/06/15 om 20:19: Good evening all, An exit that I have been running for over one month now has not yet achieved the Exit flag in arm/atlas (I know it is working because regular spam/hacking/abuse emails I am receiving). I though this was related to recent bwauth issue, but have concerns now because the exit now has a Guard flag. I think the problem will lie in the torrc and some mistake in the config. Please can I ask for some advice on where the mistake might be? I have pasted torrc below, with sensitive information changed in the brackets <>. Thanks very much Spiros #:~ cat /etc/tor/torrc RunAsDaemon 1 DataDirectory /var/lib/tor ControlPort 9051 CookieAuthentication 1 ORPort 443 ORPort [<<valid IPv6 address>>]:9090 Nickname <<nickname of this exit>> RelayBandwidthRate 10 MB RelayBandwidthBurst 12.5 MB DirPort 9030 DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily <<nicknames of other exits and relays>> ExitPolicy accept *:20-23 ExitPolicy accept *:53 ExitPolicy accept *:79-81 ExitPolicy accept *:88 ExitPolicy accept *:110 ExitPolicy accept *:143 ExitPolicy accept *:1194 ExitPolicy accept *:5900 ExitPolicy accept *:8008 ExitPolicy accept *:8080 ExitPolicy accept *:8082 ExitPolicy accept *:8332-8333 ExitPolicy accept *:50002 ExitPolicy reject *:* ExitPolicy reject6 *:* IPv6Exit 1 DisableDebuggerAttachment 0 _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

No Exit flag on Exit node
by spiros_spiros＠freemail.gr 25 Jun '15

25 Jun '15

Good evening all, An exit that I have been running for over one month now has not yet achieved the Exit flag in arm/atlas (I know it is working because regular spam/hacking/abuse emails I am receiving). I though this was related to recent bwauth issue, but have concerns now because the exit now has a Guard flag. I think the problem will lie in the torrc and some mistake in the config. Please can I ask for some advice on where the mistake might be? I have pasted torrc below, with sensitive information changed in the brackets <>. Thanks very much Spiros #:~ cat /etc/tor/torrc RunAsDaemon 1 DataDirectory /var/lib/tor ControlPort 9051 CookieAuthentication 1 ORPort 443 ORPort [<<valid IPv6 address>>]:9090 Nickname <<nickname of this exit>> RelayBandwidthRate 10 MB RelayBandwidthBurst 12.5 MB DirPort 9030 DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily <<nicknames of other exits and relays>> ExitPolicy accept *:20-23 ExitPolicy accept *:53 ExitPolicy accept *:79-81 ExitPolicy accept *:88 ExitPolicy accept *:110 ExitPolicy accept *:143 ExitPolicy accept *:1194 ExitPolicy accept *:5900 ExitPolicy accept *:8008 ExitPolicy accept *:8080 ExitPolicy accept *:8082 ExitPolicy accept *:8332-8333 ExitPolicy accept *:50002 ExitPolicy reject *:* ExitPolicy reject6 *:* IPv6Exit 1 DisableDebuggerAttachment 0

2 1

Qualities of a good relay (Sean Saito)
by saitosean＠ymail.com 25 Jun '15

25 Jun '15

I’m currently working with Dr. Virgil Griffith on Roster, a tor project that aims to reward relay operators with good relays. Right now we are brainstorming how to measure/quantify a good relay. Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users? Thanks, Sean

9 9

Re: [tor-relays] Qualities of a good relay (Sean Saito)
by Magnus Hedemark 25 Jun '15

25 Jun '15

These ideas are quite good. I think it would be interesting for a partner organization like the EFF maybe to gamify Tor relay best practices by issuing Mozilla type merit badges [ http://openbadges.org/ ] to relay operators. Setting it up is not free, volunteer time is not free, but it's a way to recognize volunteers in meaningful ways that does not require sending out tee shirts around the world. Importantly, badges should also be revoked if a relay operator is found to be behaving in less than meritorious ways. This is easily done. [ https://github.com/mozilla/openbadges-backpack/wiki/Revoking-Issued-Badges ] Magnus : E0B7C731568AC72AE848EDE91F857A3FED19ED0B @Magnus919 Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. -------- Original Message -------- Subject: Re: [tor-relays] Qualities of a good relay (Sean Saito) Time (GMT): Jun 25 2015 15:12:17 From: moritz(a)torservers.net To: tor-relays(a)lists.torproject.org Hi Sean, On 06/24/2015 03:07 AM, saitosean(a)ymail.com wrote: > Besides the obvious requirements of a good relay (e.g. speed, > geo-diversity, constant uptime), what qualities make a relay valuable to > the Tor network and its users? George posted some ideas a while ago: https://lists.torproject.org/pipermail/tor-dev/2014-July/007181.html I also remember another list of "diversity criteria" that someone posted, but I can't remember who or in which thread. -- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Let's talk incentives: addressing the social questions
by Ori Shimony 25 Jun '15

25 Jun '15

Hi All, I am an undergraduate researcher at the University of Virginia looking into the Tor Incentives Problem. I recently started running an exit-relay and plan on finding effective ways of encouraging others to do so as well! As a student of Computer Science and Anthropology, I am prioritizing both the technical and social angles of Tor's ecosystem in my approach to this problem. Thus far, many of the unanswered social questions regarding motivation and Tor have barred progress in efforts to scale the relay community. It is my objective to move this issue forward by conducting systematic research on the human-systems underlying Tor while developing proposals grounded in these socio-technical realities. One idea I’ve had is to discuss these issues and potential approaches one-on-one with some of the individuals currently operating relays. I think it would be really helpful to hear your ideas, questions, and personal insights on relay-volunteering and its future. If you are interested please email me at os7hf(a)virginia.edu with dates/times that would be convenient for a Skype or phone call. For general questions, comments, concerns, etc. feel free to respond on the mailing list as well. Thanks, Ori

1 0

Ports 465 and 587 vanished from reduced exit policy?
by Mike Perry 25 Jun '15

25 Jun '15

It appears that some years ago someone quietly removed port 465 and 587 from the reduced exit policy at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy without an explanation. I've added them back in, since these ports should only be used for user-authenticated SMTP, and not spam. Has anyone experienced any abuse from these ports that involved non-authenticated mail/spam? Otherwise, it seems that exit operators who were using the reduced exit policy should consider updating their polices to include these ports. -- Mike Perry

4 3

Re: [tor-relays] Qualities of a good relay (Sean Saito)
by saitosean＠ymail.com 25 Jun '15

25 Jun '15

Wow, thank you all for the suggestions! Hope to implement these soon. Would definitely appreciate more ideas too. Sean

4 4

Fwd: [Site5 #TZZN-12908]: DMCA Complaint: mybox.ganton.ca
by Bruce Ganton 25 Jun '15

25 Jun '15

Any advice on how to handle the following?? bg -------- Forwarded Message -------- Subject: [Site5 #TZZN-12908]: DMCA Complaint: mybox.ganton.ca Date: Wed, 24 Jun 2015 21:29:24 +0000 From: Site5 Level 2 Support <support(a)site5.com> To: bganton(a)tanglewood-cottage.ca <bganton(a)tanglewood-cottage.ca> <http://mandrillapp.com/track/click/14822339/www.site5.com?p=eyJzIjoiR3hNYjd…> [TZZN-12908]: DMCA Complaint: mybox.ganton.ca Carl Carl's Bio <http://mandrillapp.com/track/click/14822339/www.site5.com?p=eyJzIjoiUmlOVEd…> Tell us how we are doing: Good <http://mandrillapp.com/track/click/14822339/survey.site5.com?p=eyJzIjoiVWla…> Bad <http://mandrillapp.com/track/click/14822339/survey.site5.com?p=eyJzIjoiSG9R…> Greetings, Thank you for contacting Site5! Your inquiry has been assigned a ticket number (available in the subject of this email). Please include this string in the subject line of all future correspondence about this issue (or you can simply reply to this message with the ticket ID in the subject). We look forward to assisting you. If there is anything else we can do for you, please don't hesitate to let us know! Best Regards, The Site5 Support Team ------------ Hello Bruce, We are writing to you in connection with the below-pasted e-mail from the third party claimant specified therein (the Claimant) regarding certain materials contained in the specified web site mybox.ganton.ca that are infringing upon the Claimants intellectual property rights (the Infringing Materials). ***NOTE TO WORLD WIDE WEB HOSTING, LLC: PLEASE FORWARD THIS ENTIRE NOTICE TO ACCOUNT HOLDER OF IP ADDRESS 108.174.157.60 at 2015-06-23 00:39:23 North American Eastern Time*** June 23, 2015 Re: Notice of Unauthorized Use of Copyrights Owned by Two Out of Ten Productions Inc, Case #: U145963094 CEG TEK International ("CEG") represents Two Out of Ten Productions Inc, who owns all right, title and interest, including copyrights, in and to the work listed below (hereinafter the "Work"). (Some individuals may find certain words in titles of works to be offensive. CEG apologizes in advance if this is the case.) This notice is intended solely for the primary World Wide Web Hosting, LLC service account holder. Someone using this account has engaged in the unauthorized copying and/or distribution of the Work listed below. Evidence: Work Title: Odd Thomas Copyright Owner: Two Out of Ten Productions Inc Unauthorized File Name: Odd.Thomas.BRRip.XviD.AC3-WAR Unauthorized Hash: 69081b805ad400ef03f93f327a361d3d22176c48 Unauthorized File Size: 1486277285 bytes Unauthorized Protocol: BitTorrent Timestamp: 2015-06-23 00:39:23 North American Eastern Time Unauthorized IP Address: 108.174.157.60 Unauthorized Port: 50142 The following files were included in the unauthorized copying and/or distribution: File 1: Odd.Thomas.BRRip.XviD.AC3-WAR/wthomas.avi CEG TEK International ("CEG") hereby notifies you that unauthorized copying and/or distribution of Two Out of Ten Productions Inc's Work listed above is a violation of the U.S. Copyright Act, 17 U.S.C. 106. In this regard, request is hereby made that you and all persons using this account immediately and permanently cease and desist from unauthorized copying and/or distribution of the Work. CEG informs you that you may be held liable for monetary damages, including court costs and/or attorney fees if a lawsuit is commenced against you for unauthorized copying and/or distribution of the Work listed above. You have until Thursday, July 23, 2015 to access the settlement offer and settle online. To access the settlement offer, please visit https://www.copyrightsettlements.com/ and enter Case #: U145963094 and Password: usp7k. To access the settlement offer directly, please visit https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Information: Direct Settlement Link: https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Website: https://www.copyrightsettlements.com/ Case #: U145963094 Password: usp7k If you fail to respond or settle within the prescribed time period, the above matter may be referred to attorneys representing the Work's owner for legal action. At that point the original settlement offer will no longer be an option, and the settlement amount will increase significantly. Nothing contained or omitted from this correspondence is, or shall be deemed to be either a full statement of the facts or applicable law, an admission of any fact, or waiver or limitation of any of the Two Out of Ten Productions Inc's rights or remedies, all of which are specifically retained and reserved. The information in this notice is accurate. CEG has a good faith belief that use of the material in the manner complained of herein is not authorized by the copyright owner, its agent, or by operation of law. CEG and the undersigned declare under penalty of perjury, that CEG is authorized to act on behalf of Two Out of Ten Productions Inc. Sincerely, Ira M. Siegel, Esq. Legal Counsel CEG TEK International 8484 Wilshire Boulevard, Suite 515 Beverly Hills, CA 90211 Toll Free: 877-526-7974 Email: support(a)cegtek.com Website: www.copyrightsettlements.com - ----Start ACNS XML U145963094 https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Open Normal CEG TEK International Ira M. Siegel, Esq. CEG TEK International, 8484 Wilshire Boulevard, Suite 515, Beverly Hills, CA 90211 877-526-7974 support(a)cegtek.com World Wide Web Hosting, LLC United States abuse(a)worldwidewebhosting.com 2015-06-23T04:39:23Z 108.174.157.60 50142 P2P 1 2015-06-23T04:39:23Z Odd Thomas Odd.Thomas.BRRip.XviD.AC3-WAR 1486277285 Movie 69081b805ad400ef03f93f327a361d3d22176c48 DMCA Odd Thomas true true 5 June 23, 2015 Re: Notice of Unauthorized Use of Copyrights Owned by Two Out of Ten Productions Inc, Case #: U145963094 CEG TEK International ("CEG") represents Two Out of Ten Productions Inc, who owns all right, title and interest, including copyrights, in and to the work listed below (hereinafter the "Work"). (Some individuals may find certain words in titles of works to be offensive. CEG apologizes in advance if this is the case.) This notice is intended solely for the primary World Wide Web Hosting, LLC service account holder. Someone using this account has engaged in the unauthorized copying and/or distribution of the Work listed below. Evidence: Work Title: Odd Thomas Copyright Owner: Two Out of Ten Productions Inc Unauthorized File Name: Odd.Thomas.BRRip.XviD.AC3-WAR Unauthorized Hash: 69081b805ad400ef03f93f327a361d3d22176c48 Unauthorized File Size: 1486277285 bytes Unauthorized Protocol: BitTorrent Timestamp: 2015-06-23 00:39:23 North American Eastern Time Unauthorized IP Address: 108.174.157.60 Unauthorized Port: 50142 The following files were included in the unauthorized copying and/or distribution: File 1: Odd.Thomas.BRRip.XviD.AC3-WAR/wthomas.avi CEG TEK International ("CEG") hereby notifies you that unauthorized copying and/or distribution of Two Out of Ten Productions Inc's Work listed above is a violation of the U.S. Copyright Act, 17 U.S.C. 106. In this regard, request is hereby made that you and all persons using this account immediately and permanently cease and desist from unauthorized copying and/or distribution of the Work. CEG informs you that you may be held liable for monetary damages, including court costs and/or attorney fees if a lawsuit is commenced against you for unauthorized copying and/or distribution of the Work listed above. You have until Thursday, July 23, 2015 to access the settlement offer and settle online. To access the settlement offer, please visit https://www.copyrightsettlements.com/ and enter Case #: U145963094 and Password: usp7k. To access the settlement offer directly, please visit https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Information: Direct Settlement Link: https://www.copyrightsettlements.com/?u=U145963094&p=usp7k Settlement Website: https://www.copyrightsettlements.com/ Case #: U145963094 Password: usp7k If you fail to respond or settle within the prescribed time period, the above matter may be referred to attorneys representing the Work's owner for legal action. At that point the original settlement offer will no longer be an option, and the settlement amount will increase significantly. Nothing contained or omitted from this correspondence is, or shall be deemed to be either a full statement of the facts or applicable law, an admission of any fact, or waiver or limitation of any of the Two Out of Ten Productions Inc's rights or remedies, all of which are specifically retained and reserved. The information in this notice is accurate. CEG has a good faith belief that use of the material in the manner complained of herein is not authorized by the copyright owner, its agent, or by operation of law. CEG and the undersigned declare under penalty of perjury, that CEG is authorized to act on behalf of Two Out of Ten Productions Inc. Sincerely, Ira M. Siegel, Esq. Legal Counsel CEG TEK International 8484 Wilshire Boulevard, Suite 515 Beverly Hills, CA 90211 Toll Free: 877-526-7974 Email: support(a)cegtek.com Website: www.copyrightsettlements.com]]> - ----End ACNS XML This is an automated email. If you have questions or concerns, please visit us at http://www.copyrightsettlements.com/contact_us.html. Replies sent to dmca(a)cegtek.com are not read. Please review the following complaint and follow up with us to let us know the steps you intend to take to resolve this. Failure to follow up within that time may lead to suspension of your account.Please note that under the Digital Millennium Copyright Act, you have the right to file a counter-notice claiming that either (a) that the Claimant is wrong and that the Infringing Material is lawfully posted on the Web Site or (b) that the Infringing Material has been misidentified. You can use this online form at http://support.scribd.com/entries/22993-DMCA-counter-notification-template which is an editable template containing all the required elements for counter-notification which you can send back to us. Thanks, Carl B. Abuse Administrator, Site5.com Ticket Details =================== Ticket ID: TZZN-12908 Department: Level 2 Support Status: Awaiting Customer Reply Backstage Login <http://mandrillapp.com/track/click/14822339/backstage.site5.com?p=eyJzIjoiV…> | Service Notices <http://mandrillapp.com/track/click/14822339/forums.site5.com?p=eyJzIjoiOG95…> | Support Center <http://mandrillapp.com/track/click/14822339/www.site5.com?p=eyJzIjoiR3JhX3N…> | Knowledge Base <http://mandrillapp.com/track/click/14822339/kb.site5.com?p=eyJzIjoiNk1ITGJJ…>

3 2

Re: [tor-relays] Fwd: [Site5 #TZZN-12908]: DMCA Complaint: mybox.ganton.ca
by tqr2813d376cjozqap1l＠tutanota.com 25 Jun '15

25 Jun '15

Send back a reply using this template: https://www.torproject.org/eff/tor-dmca-response.html

1 0

A bridge too far
by jchase 24 Jun '15

24 Jun '15

Hello, Can anybody help me figure out why my bridge has stopped showing the flags fast, running and stable? Especially stable, I would love to get that flag back. I run two bridges, on two different Rasp Pi's, the one with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E16499 . The other with a globe fingerprint of 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . The first bridge runs with obfs 3 & 4 on a Pi 2. It seems I lost the stable flag around the time I got obfs 4 up and running. The second bridge runs only with obfs 3 on an older Pi. I've read that the stable flag is quite handy. Any ideas about how I can get it back? Greetings, J Chase

3 2