[tor-relays] Amazon abuse report

Gordon Morehouse gordon at morehouse.me
Sun Nov 3 16:14:44 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Paritesh Boyeyoko:
> On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
> 
>> Completely aside from the ethical and censorship-related buzzsaw
>> you're about to run into for posting this (perennial) question, I
>> believe some actual developers on Tor have written a paper about
>> the problems with Bittorrent et al (and I think there's a more
>> specific one than the Why Tor Is Slow[1] paper) but I can't
>> currently find it.  Anybody know?
>> 
>> 1. 
>> https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
>>
>>
>> 
NB: the above paper is from 2009.
> 
> I've just had a quick scan of that paper and it makes for an
> interesting read. :)  I'm going to go away and read it properly but
> a couple observations.

And I swear there's a more bittorrent-specific paper but I can't find it.

> 2.3 Throttle certain protocols at the client side I agree this is
> not a good idea BUT it sparked off another idea in my head.  In 
> order to get better utilisation of slower relays, would it be worth
>  introducing a behaviour whereby "slow" circuits are deliberately
> built for low volume traffic?
> 
> For example, sending email and IM messages doesn't (usually)
> require a huge amount of bandwidth, so when the Tor client detects
> that a user wants to send/receive data on certain slow ports such
> as POP3, IMAP4, MSA and Jabber it deliberately builds a "slow"
> circuit to handle that traffic.  Obviously it would have to be port
> based, but since people tend to send data on well-known ports, it
> shouldn't be an issue.

That might have at least been thought about, but it's a good idea.
It'd also help with better allocating bandwidth offered by "slow" or
"fast but at the bottom end" nodes, which I've seen devs in here say
they are well aware is not optimally allocated.

> 
> I think this would play well with the circuit-bonding work here
> 
> http://freehaven.net/anonbib/#pets13-splitting
> 
> 
> 3.1.2 Better Support for relay operators This caught my eye: "We
> lose relays when the operator reboots and forgets to set up the
> relay to start on boot."  Does installing the .deb package (for 
> example) not configure Tor to start on boot, in the same way that
> Apache would be?  I ask because I haven't rebooted my VPS yet. :p

I've not seen this with .debs, but Windows?  If so, maybe the "restart
on reboot?" dialog - if there is one, and not a hidden checkbox -
should be front and center when opting to relay traffic.

> 3.1.3  Facebook app to show off your relay I liked this bit:
> "Opportunities for expansion include allowing relay operators to
> form “teams”, and for these teams to be ranked on the contribution
> to the network. (Real world examples here include the SETI 
> screensaver and the MD5 hash crack challenges.)"

I'd go for an embeddable badge, first.  Then maybe a Facebook app.
It's only a hunch, but I think we'd get a lot more mileage out of an
embeddable badge (for web sites, tumblr, and anything else tumblr-like
that allows embedding) than out of a Facebook app, though if there
were time, money and spoons[1] to do both, I'd certainly do both with
the Facebook thing coming second.  Well, maybe.  Nobody should be on
Facebook, least of all anybody who is running Tor for the right
reasons, but we have reality to contend with here.

My hunch is based on demographics, BTW. :P

> What would be really interesting would be to find sponsors (read:
> hosters) willing to put their name to it and gain/risk some
> publicity.

Start by asking XMission, GANDI and maybe even (though they don't do
VPS) NearlyFreeSpeech.net if this ever happens.  Also, dig back into
news articles about industry response to the NSA wiping its butt with
the Fourth Amendment, and see which VPS providers were yelling the
loudest, especially the mom-n-pop to mid-tier providers.  $.02.

Best,
- -Gordon M.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJSdnZyAAoJED/jpRoe7/uj0ywH/3c9d5uTsVJWtSkwd/YSuVpU
+Q5Az2Wd1Pes45z8Zx/fRtvhlJ7/qtZloXxVyDLg7KjUjJktiCgJaDO7j8mw9/NO
S5W2JFHtr8j8AukDdMzCpocD06O1Chhq7cmq+DzdZji+jENR2iB4jbKzvNNkVCNg
duAiPnNPiEl/6m5ViiFuO38P+qag0nNN4lnnOnHcvodXfmU4Qxgzd/zwEoKpF0ET
qKOmb3zKsxF3bqq1Ab2+hLafhdkJYThOszbJuiCwA+q+D94lDIJ5nFftq4lhWqN2
WcGASJpzOLR9CnkykMPiTYHVuM2RZZWTEeVlN10eAynpzO9qeNYFHk2KTeUoZsY=
=Owji
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x1EEFFBA3.asc
Type: application/pgp-keys
Size: 1749 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20131103/a09849ab/attachment.key>


More information about the tor-relays mailing list