> The simplest way would be to add a VE service on a TOR relay
> publishing a browser. You would not only be asking TOR relay
> providers to donate some bandwidth but also some processing power.
So I run the relay with a VE and now I get to see what everyone using
that VE is doing? I am not sure t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I would have a question regarding the bw-flags graphs on metrics.tpo [1]
"guard bw history"
a) Does this include the entire accumulated traffic of relays having
the guard flag? (which would include the traffic of a guard relay
acting as a middl
On 07/31/2014 09:09 AM, Martin Kepplinger wrote:
> Am 2014-07-31 01:02, schrieb Cypher:
>> I'm about to fire up another exit relay and I want to make sure users
>> are protected from picking both of my relays in the same chain. So I
>> came across the MyFamily variable in the torrc file. I have two
On Thu, Jul 31, 2014 at 01:58:18PM -0700, Seth David Schoen wrote:
> Roger Dingledine writes:
>
> > But in this particular case I'm stuck, because the arms race is so
> > lopsidedly against us.
> >
> > We can scan for whether exit relays handle certain websites poorly,
> > but if the list that we
Roger Dingledine writes:
> But in this particular case I'm stuck, because the arms race is so
> lopsidedly against us.
>
> We can scan for whether exit relays handle certain websites poorly,
> but if the list that we scan for is public, then exit relays can mess
> with other websites and know the
On Thu, Jul 31, 2014 at 04:12:33PM -0400, Philipp Winter wrote:
> One good example is documented in a recent research paper [0]. Section
> 5.2 describes how we chased a group of related malicious exit relays
> over several months. At some point the attackers began to sample MitM
> attempts and ta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
>>> Will dir auth ops make the list of rejected relays including
>>> its reason for removal available to the public for
>>> transparency?
> We did this for a time... ... but it was contentious so couldn't be
> continued.
Could you elaborate (or add
Roger Dingledine wrote:
On the other hand, there are some real downsides to having large relays
where we don't know the operators. We know the operators of many of
the large relays in the network, but there are many more where we don't
know them.
And of course, confirming that some email address
On Thu, Jul 31, 2014 at 07:21:59PM +, Nusenu wrote:
> > I think we need to distinguish between the report and the
> > discussion. Ultimately, a report that is acted upon *cannot* remain
> > secret. As soon as a relay gets the BadExit flag, the operator can
> > figure out that they got caught.
>> I believe that the mere fact that a relay was blocked (via BadExit
>> or reject) can be published.
>
> Will dir auth ops make the list of rejected relays including its
> reason for removal available to the public for transparency?
We did this for a time...
https://trac.torproject.org/projects/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
>> What would be the catch with making these reports and discussion
>>> public? Would it help bad actors? They will eventually find out
>>> about the consensus changes anyway, no?
> I think we need to distinguish between the report and the
> discussi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> I believe that the mere fact that a relay was blocked (via BadExit
> or reject) can be published.
Will dir auth ops make the list of rejected relays including its
reason for removal available to the public for transparency?
>> where can we find a
On Thu, Jul 31, 2014 at 08:18:07PM +0200, Öyvind Saether wrote:
> Thank you for this secret information. Please consider adding it to the
> MANUAL PAGE since I've had my torrc since 2008 and it's not got any of
> that classified information in it.
Well, it certainly isn't meant to be a secret. Yo
> Hm? ContactInfo is just a string. You can set it however you like.
>
> Here's the stanza in the torrc file:
>
> ## Administrative contact information for this relay or bridge. This
> line ## can be used to contact you if your relay or bridge is
> misconfigured or ## something else goes wrong. N
On Thu, Jul 31, 2014 at 07:58:34PM +0200, Öyvind Saether wrote:
> Too bad "ContactInfo email_address" in torrc isn't "ContactInfo
> email_address gpgkey" or alternatively
>
> ContactEmail x@y
> ContactKey numbers
Hm? ContactInfo is just a string. You can set it however you like.
Here's the stan
> A bad-relays mailing list would IMO take a degree of care to do
> right, considering that email gets gathered at the packet level by
> intelligence agencies who are expected to be initiating attacks.
> Sensitive stuff would belong as GPG or PGP emails or similar. Juicy
> details regarding bad-
On 07/31/2014 11:44 AM, Joe Btfsplk wrote:
> Wow, I'm surprised no one has questioned this before or has a reasonable
> explanation.
> Why Panopticlick's total estimated entropy, *reported in the sentence
> _above_ their results table,* is much less than the sum of individual
> parameters' entropie
Wow, I'm surprised no one has questioned this before or has a reasonable
explanation.
Why Panopticlick's total estimated entropy, *reported in the sentence
_above_ their results table,* is much less than the sum of individual
parameters' entropies - shown in the table:
"_Currently, we estimate
And since it's not possible to do this right without any leaks due to
software bugs, planted flaws and insiders, the only thing it will lead
to is to make it impossible for the users to verify the decisions
leading up to which servers are bad. The NSA will still get your
precious warnings.
On Thu,
Am 2014-07-31 01:02, schrieb Cypher:
> I'm about to fire up another exit relay and I want to make sure users
> are protected from picking both of my relays in the same chain. So I
> came across the MyFamily variable in the torrc file. I have two
> questions about how to properly set this variable:
On 07/31/2014 02:45 PM, Lunar wrote:
> Mike Fikuart:
>> My thought was that [hiddenservice].onion would be dealt with by the
>> Tor NameServer to return the hostname (derived from public key).
>
> So if I understand correctly, you would like some entity to keep
> a directory of human memorizable
Mike Fikuart:
> My thought was that [hiddenservice].onion would be dealt with by the
> Tor NameServer to return the hostname (derived from public key).
So if I understand correctly, you would like some entity to keep
a directory of human memorizable names pointing to hidden service
addresses.
The
Thanks for the response Ondrej.
I was thinking specifically for the .onion addresses as opposed to the
conventional www addressing. When the client first recognises the .onion
domain, could a DNS be set up within Tor dealing only with .onion
hostnames/domain space and conventional DNS requests
Actually...
A bad-relays mailing list would IMO take a degree of care to do right,
considering that email gets gathered at the packet level by
intelligence agencies who are expected to be initiating attacks.
Sensitive stuff would belong as GPG or PGP emails or similar. Juicy
details regarding
24 matches
Mail list logo
