2011/2/14 Julie C ju...@h-ck.ca:
If this BadExit policy is being
made up ad-hoc, that's fine by me. If the offending Tor node operators want
to stand up and defend themselves, or their choices, that's fine too.
So, I as a Tor Node Operator now have to defend myself, because it's a
priviledge
On 2/15/2011 5:00 AM, morphium wrote:
2011/2/14 Julie Cju...@h-ck.ca:
If this BadExit policy is being
made up ad-hoc, that's fine by me. If the offending Tor node operators want
to stand up and defend themselves, or their choices, that's fine too.
So, I as a Tor Node Operator now have to
On Monday 14 February 2011 18:11:42 Dave U. Random wrote:
SHUT UP EELBASH!
I'm not eelbash, nor do I know who eelbash is (I've heard rumors that eelbash
is wormcast, but I don't remember what that was about, it was years ago).
I never made the claim this was safer.
Of course, not quoted as such. Plaintext anywhere is risky. Yet
this entire thread is about sniffing. How plaintext-only exits
somehow equate to sniffing. And how badexiting plaintext-only exits
somehow equates to reducing that risk. Both are weak premises.
So, with everything said, could we now please Un-BadExit the nodes
that were affected?
Thanks!
morphium
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body.
Thus spake morphium (morph...@morphium.info):
So, with everything said, could we now please Un-BadExit the nodes
that were affected?
Sure, dude. Since you've read everything that was said, I take it
you're volunteering to contact the other node operators and ask them
to give reasons for why
Am 14.02.2011 14:41, schrieb morphium:
So, with everything said, could we now please Un-BadExit the nodes
that were affected?
the whole discussion didn't change my mind. I still support the idea of
flagging them as bad exit.
regards Olaf
the whole discussion didn't change my mind. I still support the idea of
flagging them as bad exit.
Same. Mike gave some good reasons for flagging them weeks ago and I've
yet to see much else besides ranting that seems to ignore most of this
thread. -Damian
Sure, dude. Since you've read everything that was said, I take it
you're volunteering to contact the other node operators and ask them
to give reasons for why they chose their exit policy?
So please BadExit all nodes without contact email, if they don't
explain why they chose the default exit
On Mon, 2011-02-14 at 14:41 +0100, morphium wrote:
So, with everything said, could we now please Un-BadExit the nodes
that were affected?
Sorry, but this has been a long thread and I want to try to make sure I
understand something important.
Is it true or false that traffic was actually
On Mon, 14 Feb 2011, morphium wrote:
Sure, dude. Since you've read everything that was said, I take it
you're volunteering to contact the other node operators and ask them
to give reasons for why they chose their exit policy?
So please BadExit all nodes without contact email, if they don't
I suppose the anarchist genes in me are not strong enough. I have to agree
with Mike Perry's arguments, given his credibility, and his clearer
perspective than most of the rest of us. If this BadExit policy is being
made up ad-hoc, that's fine by me. If the offending Tor node operators want
to
On Mon, 2011-02-14 at 17:41 +, John Case wrote:
On Mon, 14 Feb 2011, Ted Smith wrote:
Sorry, but this has been a long thread and I want to try to make
sure I
understand something important.
Is it true or false that traffic was actually exiting through
gatereloaded et all?
I
On 2/14/2011 7:48 AM, grarpamp wrote:
[snip]
If another example is needed, not that one is; Corporate, edu and
other LAN's sometimes think they can block 'ooo, encryption bad'
ports so they can watch their user's plaintext URL's with their
substandard vendor nanny watch tool of the day. All the
On Monday 14 February 2011 14:17:45 Aplin, Justin M wrote:
However, I see no reason why providing an anonymous contact email would
be so hard. Certainly if you're going out of your way to avoid [insert
conspiracy of choice] in order to run a node, you have the skills to use
one of the hundreds
Hello Julie,
On Mon, 14 Feb 2011, Julie C wrote:
I suppose the anarchist genes in me are not strong enough. I have to agree
with Mike Perry's arguments, given his credibility, and his clearer
perspective than most of the rest of us. If this BadExit policy is being
made up ad-hoc, that's fine
On 2011-02-14 John Case wrote:
Where's the answer to this ? I chose edge-case scenarios above, for
sure, but this is the real meat of the implementation of your plans,
and I'd like to know if you've given any thought to this whatsoever.
What _is_ the proper corresponding open port for 25 ?
On Mon, Feb 14, 2011 at 4:32 PM, John Case c...@sdf.lonestar.org wrote:
Hello Julie,
On Mon, 14 Feb 2011, Julie C wrote:
I suppose the anarchist genes in me are not strong enough. I have to agree
with Mike Perry's arguments, given his credibility, and his clearer
perspective than most of the
Hi Geoff,
On Sat, 12 Feb 2011, Geoff Down wrote:
There are a small number of easily identifiable cons to letting an exit
run like this, and there are an unlimited number of unknown pros to
letting an exit run like this. You should know this.
Leaving aside the original question of whether
On Mon, 31 Jan 2011, Andrew Lewman wrote:
In my opinion, judging a relay based on exit policy is a slippery slope
we don't want to go down. We never claim to make using Tor alone safer
than using the Internet at large. Whether the creep is at Starbucks
sniffing the wifi or running a relay is
On Sat, Feb 12, 2011 at 5:35 PM, John Case c...@sdf.lonestar.org wrote:
That's fair.
Instead of stressing the boundless set of pros, I will discuss a single,
specific pro, and that is the idea that open, arbitrary systems provide a
foundation upon which to build surprising and unexpected
is that gatereloaded is a bad exit and is doing
something nasty. I just don't think this small set of known dangers is
worth throwing out an UNLIMITED set of unknown benefits for.
On Fri, 11 Feb 2011 17:44 +, John Case c...@sdf.lonestar.org
wrote:
There are a small number of easily identifiable cons to letting an exit
run like this, and there are an unlimited number of unknown pros to
letting an exit run like this. You should know this.
Leaving aside the
On Mon, 31 Jan 2011 11:30:20 -0500 Andrew Lewman and...@torproject.org
wrote:
In my opinion, judging a relay based on exit policy is a slippery slope
we don't want to go down. We never claim to make using Tor alone safer
than using the Internet at large. Whether the creep is at Starbucks
Been a fencesitter on this since posting the note about recording
traffic that helped send this thread over the top. For once, I'm
in agreement with Scott :) (and others)
Badexiting based on exit policy seems rather silly as it will prevent
nothing. And because of that, doing so is security
Thus spake grarpamp (grarp...@gmail.com):
Exit policy is currently at the operator's pleasure, need and design.
If exit policy mandates will help solve some Tor scalability or
attack vector issues, in a substantive way, from an engineering
standpoint, fine. But please, don't claim it makes
On Thu, 10 Feb 2011, Mike Perry wrote:
Exit policy is currently at the operator's pleasure, need and design.
If exit policy mandates will help solve some Tor scalability or
attack vector issues, in a substantive way, from an engineering
standpoint, fine. But please, don't claim it makes users
On Fri, Feb 11, 2011 at 6:58 AM, John Case c...@sdf.lonestar.org wrote:
No, there is no _technical_ reason to operate an exit in this fashion. There
is no reason, from a myopic, borderline autistic view of the externalities
involved, to run an exit in this fashion.
However, I can think of
On Fri, Feb 11, 2011 at 12:58 AM, John Case c...@sdf.lonestar.org wrote:
I think these reasons should be worked around or ignored.
I think you, and others on that side of this argument have a very, very
myopic view of the constraints and non-technical decisions that go into
running a
On Mon, 31 Jan 2011 11:09:51 +0100 Olaf Selke olaf.se...@blutmagie.de
wrote:
On 31.01.2011 10:52, morphium wrote:
As I stated above, it's not a good idea to BadExit them, because it
puts more load on the servers, that DO support https i.e. - and makes
them slower.
I disagree Morphium's
On Mon, 31 Jan 2011 11:17:27 +0100 morphium morph...@morphium.info
wrote:
2011/1/31 Olaf Selke olaf.se...@blutmagie.de:
I disagree Morphium's position mainly for the same reasons Mike and Jake
already pointed out. If the operators really care about their nodes
they'll certainly contact Tor
On Sat, 29 Jan 2011 23:23:55 -0800 Mike Perry mikepe...@fscked.org
wrote:
Thus spake Eddie Cornejo (corn...@gmail.com):
I believe that allowing these nodes sends a message that we are OK
with people monitoring plaintext traffic, because it is anonymized. We
have never been OK with
mi nt wrote:
On Mon, Jan 31, 2011 at 08:39:29PM -0500, Gregory Maxwell wrote:
The chances of having your traffic logged by malicious operators, known or
unknown, allowing traffic on 443 or not, can be minimized by not using
Tor.
Just saying! :-)
--
m...@sdf.lonestar.org
SDF Public
Currently, 5 nodes exit to *only* plaintext ports for web and email.
There are about 50 others that exit to the plaintext versions for web
or email.
I don't see what the issue is here. Not all e-mail services support
HTTPS. Or are you saying: if there is a HTTPS option as for Gmail the 50
We already filter exit nodes based on suspicion by defaulting
ExcludeSingleHopRelays to true (the reason for that being that single
hop exits are more likely to be passively monitoring data).
Can you please say a little more about this for all of us who are not au
fait with all command
Can you please say a little more about this for all of us who are not au
fait with all command options?
Relays have an option to allow single hop connections through them,
which is off by default. If relays *do* set this and allow single hop
circuits through themselves then Tor clients by
On Tue, Feb 1, 2011 at 6:31 PM, Damian Johnson atag...@gmail.com wrote:
In both of those cases we took harder measures based on suspicion of
malicious intent than we are with these plaintext-only relays. Despite
its name, the BadExit flag really isn't a big whoop - the relays are
still
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l1285
On Tue, Feb 1, 2011 at 4:10 PM, Joseph Lorenzo Hall joeh...@gmail.com wrote:
On Tue, Feb 1, 2011 at 6:31 PM, Damian Johnson atag...@gmail.com wrote:
In both of those cases we took harder measures based on suspicion of
Do you have a rational reason why we should allow people to carry the
unencrypted version of a service but not the encrypted one, other than
Well, they could be bad actors even with a good policy!
As I stated above, it's not a good idea to BadExit them, because it
puts more load on the
On 31.01.2011 10:52, morphium wrote:
As I stated above, it's not a good idea to BadExit them, because it
puts more load on the servers, that DO support https i.e. - and makes
them slower.
I disagree Morphium's position mainly for the same reasons Mike and Jake
already pointed out. If the
2011/1/31 Olaf Selke olaf.se...@blutmagie.de:
I disagree Morphium's position mainly for the same reasons Mike and Jake
already pointed out. If the operators really care about their nodes
they'll certainly contact Tor admins. Damaging Tor's reputation in the
public due to exit sniffing imo is
I can not see the Tor project won _anything_ with this decision.
I agree 100%. By all means try to identify those that are trying to
misuse the privilege of running an exit node by other means - but
solely looking at exit policies is not sufficient. All you're stating
to the community is do it
2011/1/31 Mike Perry mikepe...@fscked.org:
So when I said in my earlier post that we don't need exit capacity
that bad, I meant it. Thanks, but no thanks. You are contributing
negative productivity, and none of the non-bitorrenting exits really
will notice your absence in terms of load. Please
On 1/31/2011 6:05 AM, morphium wrote:
2011/1/31 Mike Perrymikepe...@fscked.org:
So when I said in my earlier post that we don't need exit capacity
that bad, I meant it. Thanks, but no thanks. You are contributing
negative productivity, and none of the non-bitorrenting exits really
will notice
morphium wrote:
2011/1/31 Olaf Selke olaf.se...@blutmagie.de:
I disagree Morphium's position mainly for the same reasons Mike and Jake
already pointed out. If the operators really care about their nodes
they'll certainly contact Tor admins. Damaging Tor's reputation in the
public due to exit
Mike Perry wrote:
Thus spake morphium (morph...@morphium.info):
Do you have a rational reason why we should allow people to carry the
unencrypted version of a service but not the encrypted one, other than
Well, they could be bad actors even with a good policy!
As I stated above, it's not a
On 31/01/2011 12:37, Orionjur Tor-admin wrote:
But, in the other side, it seems to me that guys which set up so such
fast nodes are not full lamers. And they probably can read this mailing
list and are able to answer us, am I wrong?
They may or may not read this list. Has anyone taken
Assuming the worse, and disregarding volunteer exit bandwidth without
some proper investigation, doesn't sound like a good approach to me...
Nobody does that, but I think its fair to say that if you want that
somebody can contact you about your node, you publish your contact
details in the
On 31/01/2011 13:11, Jan Weiher wrote:
Assuming the worse, and disregarding volunteer exit bandwidth without
some proper investigation, doesn't sound like a good approach to me...
Nobody does that, but I think its fair to say that if you want that
somebody can contact you about your node,
You make it sound as though running an Exit node is a privilege and that
people who run them somehow owe the Tor project? They're volunteering
bandwidth, for the benefit of the network.
This was not my intention. But I think it should be possible to ask a
volunteer about what he is doing?
I don't think that tor should be dictating what ports must or must not be
open on an exit node. This is after all a voluntary operation.
If people want to send unencrypted data, they will do so with or without these
5 nodes. Shutting them or others down as exits will not make up for users that
In my opinion, judging a relay based on exit policy is a slippery slope
we don't want to go down. We never claim to make using Tor alone safer
than using the Internet at large. Whether the creep is at Starbucks
sniffing the wifi or running a relay is irrelevant to me. Encouraging
people to use
On Mon, Jan 31, 2011 at 11:30 AM, Andrew Lewman and...@torproject.org wrote:
[snip]
If we're going to start censoring Tor exits based on impressions, we
might as well start blocking Tor relays that are rumoured to be run by
national intelligence agencies, criminal organizations, martians, and
- Original Message
From: Gregory Maxwell gmaxw...@gmail.com
To: or-talk@freehaven.net
Sent: Mon, January 31, 2011 6:47:37 PM
Subject: Re: Is gatereloaded a Bad Exit?
There are legitimate reasons why tor supports an operator controlled
exit policy, but no real suggestion has
Thus spake Curious Kid (letsshareinformat...@yahoo.com):
- Original Message
From: Gregory Maxwell gmaxw...@gmail.com
To: or-talk@freehaven.net
Sent: Mon, January 31, 2011 6:47:37 PM
Subject: Re: Is gatereloaded a Bad Exit?
There are legitimate reasons why tor supports
Thus spake t...@lists.grepular.com (t...@lists.grepular.com):
On 31/01/2011 13:11, Jan Weiher wrote:
Assuming the worse, and disregarding volunteer exit bandwidth without
some proper investigation, doesn't sound like a good approach to me...
Nobody does that, but I think its fair to
On 01/02/2011 00:00, Mike Perry wrote:
I don't think you can make that assumption. Maybe they just didn't want
their email address to be public for spam bots to harvest. Maybe they're
just used to not publishing their email address unless they really have
to. Safest course of action: Figure
Thus spake t...@lists.grepular.com (t...@lists.grepular.com):
But don't worry, at some point Mr. Blow et al will realize that their
packet captures stopped grabbing passwords and are only seeing
encrypted middle and guard node traffic. They'll probably show up
then, proclaiming their
These people should not be Tor nodes.
Mike, I respectfully disagree. Anyone willing to allow traffic should be
node. The tor project homepage makes no 'rules' when it
comes to running a node. If you're willing to allow any traffic you're a
suitable candidate, apparently in the opinion of the
Furthermore I would like to add that if I ran an exit I *might* just not
put contact info on it. I don't see the issue unless it's rejecting
traffic and I'm screwing up the network. Even if it was I'd figure it out
eventually. I wouldn't want you weirdos emailing me anyway ;)
--
On Mon, Jan 31, 2011 at 8:08 PM, mi nt m...@sdf.lonestar.org wrote:
These people should not be Tor nodes.
Mike, I respectfully disagree. Anyone willing to allow traffic should be
node. The tor project homepage makes no 'rules' when it
comes to running a node. If you're willing to allow any
On Sun, 30 Jan 2011, Christopher A. Lindsey wrote:
Could it be that these nodes have set these policies to reduce the
possibility of being approached because of illegal activity passing
through them? It could be they believe that they're helping with the
project and limiting their exposure as
Mike Perry wrote:
Thus spake Eddie Cornejo (corn...@gmail.com):
Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm
missing something.
Yeah, I believe you're missing the fact that these ports also contain
plaintext passwords than can be used to gain access to information
At some point, we intend to shrink exit policies further as Tor scales
to more decentralized schemes. Those exit policies will likely be
represented as bits representing subsets of ports. When that time
comes, we will very likely combine encrypted and unencrypted versions
of ports together,
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
[1] https://trac.torproject.org/projects/tor/wiki/badRelays
On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote:
At some point, we intend to shrink exit
On Sun, 30 Jan 2011 10:33:31 +0100
Jan Weiher j...@buksy.de wrote:
At some point, we intend to shrink exit policies further as Tor scales
to more decentralized schemes. Those exit policies will likely be
represented as bits representing subsets of ports. When that time
comes, we will very
2011/1/30 Damian Johnson atag...@gmail.com:
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
That was really dumb, as it puts a lot more load on the Nodes that
support encryption, and, as was mentioned before,
On 01/30/2011 01:56 AM, morphium wrote:
2011/1/30 Damian Johnson atag...@gmail.com:
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
That was really dumb, as it puts a lot more load on the Nodes that
support
On Sat, 2011-01-29 at 22:45 -0800, Mike Perry wrote:
Thus spake Eddie Cornejo (corn...@gmail.com):
Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm
missing something.
Yeah, I believe you're missing the fact that these ports also contain
plaintext passwords than
On Sat, Jan 29, 2011 at 07:46:20PM +0100, Jan Weiher wrote:
Hi,
while scrolling through the tor status page (torstatus.blutmagie.de), I
stumpled upon the following node (the reason why it came to my eye was
the long uptime):
gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92
Damian Johnson wrote:
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
[1] https://trac.torproject.org/projects/tor/wiki/badRelays
On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote:
At some point,
There's no point in putting relays flagged as BadExit into your torrc
since your client will already avoid them. However, if you want a
listing of the bad exits then it's available at:
https://trac.torproject.org/projects/tor/wiki/badRelays
As for the previous discussion of if plaintext-only
I'm aware of the fact that it is not recommended to use tor without
additional encryption, but some users do. And I dont see any reason for
only allowing unencrypted traffic than snooping?
[...]
I don't see why any of this really matters. Anyone running tor should have
the good sense to
Thus spake morphium (morph...@morphium.info):
2011/1/30 Damian Johnson atag...@gmail.com:
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
That was really dumb, as it puts a lot more load on the Nodes that
Hi,
while scrolling through the tor status page (torstatus.blutmagie.de), I
stumpled upon the following node (the reason why it came to my eye was
the long uptime):
gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92
This node looks suspicious to me, because there is no contact info
On Sat, Jan 29, 2011 at 12:46 PM, Jan Weiher j...@buksy.de wrote:
Hi,
while scrolling through the tor status page (torstatus.blutmagie.de), I
stumpled upon the following node (the reason why it came to my eye was
the long uptime):
gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D
Am 29.01.2011 20:13, schrieb Jon:
On Sat, Jan 29, 2011 at 12:46 PM, Jan Weiher j...@buksy.de wrote:
Hi,
while scrolling through the tor status page (torstatus.blutmagie.de), I
stumpled upon the following node (the reason why it came to my eye was
the long uptime):
gatereloaded 550C C972
On 2011-01-29 19:46, Jan Weiher wrote:
while scrolling through the tor status page (torstatus.blutmagie.de), I
stumpled upon the following node (the reason why it came to my eye was
the long uptime):
gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92
This node looks
Am 29.01.2011 21:27, schrieb Gitano:
On 2011-01-29 19:46, Jan Weiher wrote:
while scrolling through the tor status page (torstatus.blutmagie.de), I
stumpled upon the following node (the reason why it came to my eye was
the long uptime):
gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2
On Sat, 29 Jan 2011 19:46:20 +0100
Jan Weiher j...@buksy.de wrote:
This node looks suspicious to me, because there is no contact info
given and the exit policy allows only unencrypted traffic:
It hasn't shown up in any of the exit scans as suspicious. Lack of
contact info isn't a concern. The
Am 29.01.2011 21:44, schrieb Andrew Lewman:
On Sat, 29 Jan 2011 19:46:20 +0100
Jan Weiher j...@buksy.de wrote:
This node looks suspicious to me, because there is no contact info
given and the exit policy allows only unencrypted traffic:
It hasn't shown up in any of the exit scans as
On Sat, Jan 29, 2011 at 09:55:05PM +0100, j...@buksy.de wrote 1.3K bytes in 38
lines about:
: What kind of scans do you perform? I thought these scans do only check
: for content manipulation? I dont see how to recognize if the traffic is
: recorded?
I dont see how to recognize if the traffic is recorded?
I know people who record exit traffic, lots of it. And they
do all sorts of things with it too. Does that news trouble
you? If so, you need to readjust your thinking.
***
One could argue that recording traffic goes against the spirit of the tor
project and anonymity in general. But even if people do monitor the traffic as
long as they don't control both nodes there is little chance that the end user
can really be tracked. There is also an onus on the end user to
On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote:
I dont see how to recognize if the traffic is recorded?
I know people who record exit traffic, lots of it. And they
do all sorts of things with it too. Does that news trouble
you? If so, you need to readjust your thinking.
Thus spake Gregory Maxwell (gmaxw...@gmail.com):
On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote:
I dont see how to recognize if the traffic is recorded?
Various research groups occasionally experiment with using side
channels for detecting recording exits. Their results
Thus spake Mike Perry (mikepe...@fscked.org):
Thus spake Gregory Maxwell (gmaxw...@gmail.com):
As far as that exit policy goes, the RFC1918 blocks might be there in
an ignorant attempt to trigger the exit flag for completely benign
reasons, though sniffing sounds more likely.
I agree.
Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm
missing something.
Everyone that uses TOR should acknowlege that all data that doesn't
use encryption before entering the TOR network. It's even in the FAQ
Thus spake Eddie Cornejo (corn...@gmail.com):
Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm
missing something.
Yeah, I believe you're missing the fact that these ports also contain
plaintext passwords than can be used to gain access to information on
these and other
Howdy,
Thanks for replying.
Yeah, I believe you're missing the fact that these ports also contain
plaintext passwords than can be used to gain access to information on
these and other accounts that may or may not have ever traveled over
tor. That is the difference.
Actually, no I
Thus spake Eddie Cornejo (corn...@gmail.com):
I believe that allowing these nodes sends a message that we are OK
with people monitoring plaintext traffic, because it is anonymized. We
have never been OK with this.
Ok, I accept that this might send a message to 50ish nodes (if you ban
Jan Weiher wrote:
Of course these ports are popular, but 443 is popular as well? So for me
it looked like pick all the popular _unencrypted_ ports.
best regards,
Jan
***
To unsubscribe, send an e-mail to
grarpamp wrote:
I dont see how to recognize if the traffic is recorded?
I know people who record exit traffic, lots of it. And they
do all sorts of things with it too. Does that news trouble
you? If so, you need to readjust your thinking.
Gregory Maxwell wrote:
On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote:
Instead, I think that nodes which exit _only_ to the unencrypted
version of a service (e.g. 80 but not 443) should be excluded from
operating as exits entirely (except as enclaves). In this way these
94 matches
Mail list logo
