Re: [tor-dev] adding smartcard support to Tor

[Virgil Griffith]

This may be not quite what you want, but the Estonia E-resident card
supports basic crypto with the private key on the smart card---i.e.,
you have to physically have the card to be able to read the encrypted
mail.

There are probably more elegant solutions than plugging into the
Estonia E-resident framework, but you'll get press for using the
E-resident card---the Estonians always get happy when someone uses
their card for something novel.  Which might be a perk.

Note: I believe that, theoretically, yes, the Estonian government
could jot down your private key before it goes onto the card.  But
they are economically disincentivized from doing that.

-V

On Wed, Oct 14, 2015 at 4:08 AM, Razvan Dragomirescu
 wrote:
> Hello,
>
> I am not sure if this has been discussed before or how hard it would be to
> implement, but I'm looking for a way to integrate a smartcard with Tor -
> essentially, I want to be able to host hidden service keys on the card. I'm
> trying to bind the hidden service to a hardware component (the smartcard) so
> that it can be securely hosted in a hostile environment as well as
> impossible to clone/move without physical access to the smartcard.
>
> I have Tor running on the USBArmory by InversePath (
> http://inversepath.com/usbarmory.html ) and have a microSD form factor card
> made by Swissbit (
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> ) up and running on it. I am a JavaCard developer myself  and I have
> developed embedded Linux firmwares before but I have never touched the Tor
> source.
>
> Is there anyone that is willing to take on a side project doing this? Would
> it be just a matter of configuring OpenSSL to use the card (I haven't tried
> that yet)?
>
> Thank you,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [GSoC16] A website to improve Tor fingerprinting defenses

[Virgil Griffith]

It's unclear to me how this would be different than standard panopticlick
with >50% of the users using TBB.  But those not using TBB with had browser
statistics like the rest of the web (for example, all of the tor2web
traffic).

-V

On Sunday, 24 April 2016, Pierre Laperdrix 
wrote:

> Hi Tor Community!
>
> My name is Pierre and I'm a second year PhD student from France working
> on browser fingerprinting. I'm really fortunate that my proposal for
> this year Google Summer of Code has been been selected.
>
> My goal for this summer is to set up a website similar to Panopticlick
> or AmIUnique that will collect data to improve Tor fingerprinting
> defenses. The collected data will be used to detect if there are
> differences between browsers that could ultimately lead to a user's
> identification. With that knowledge, developers will be able to patch
> the Tor browser to prevent leak of identifiable information and
> reinforce the anonymity of Tor users. I also plan to add details on
> browser fingerprinting for users who are not familiar with the subject
> so that they may learn about its mechanisms and the potential dangers
> linked to it. I'll also try to implement a page where Tor users can see
> how far they are from an "acceptable" fingerprint so that they may tweak
> their browser in order to have a fingerprint that is shared by many more
> users.
>
> I'll officially start coding at the end of May but in the mean time,
> I'll familiarize myself with the Django framework that I plan to use and
> I'll lock down the exact set of features that I'll include in the very
> first version of the project.
> My primary mentor is Georg and my secondary mentors are Gunes and
> Nicolas. I'll post bi-weekly reports to the tor-dev mailing list and to
> my blog to inform everyone of my progress.
>
> If you have any questions about the project, don't hesitate to ask me.
> The name of the project has not been found yet so feel free to send me
> any suggestions that you may have. You can reach me here or on IRC where
> my handle is SuperOctopus.
>
> Cheers!
> Pierre
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] putting 'Nuke MyFamily' to vote (#6676)

[Virgil Griffith]

We'd obviously lose some connections if we lost MyFamily.  And I'd prefer
not to lose them.  However, if there's other needs which require the nuking
of MyFamily, my/Roster's world would not end.

-V

On Sunday, 17 April 2016, Tim Wilson-Brown - teor <teor2...@gmail.com>
wrote:

>
> > On 16 Apr 2016, at 17:13, Virgil Griffith <i...@virgil.gr <javascript:;>>
> wrote:
> >
> > I'm not wholly in favor of keeping MyFamily in its current form.  In
> Roster we simply need a way to identify when two relays are owned by the
> same operator.  Worst comes to worst we could use the email address in the
> ContactInfo, or some such.
>
> Some operators use a variant email address or ContactInfo for each relay,
> although these are in the minority.
> Others don't have any ContactInfo at all.
> I'm not sure whether any of these relays declare MyFamily or not, I'd have
> to check.
>
> I'd like to know how many relay associations we'd lose in the current
> network by removing MyFamily before we make a decision.
>
> > There have been proposals to do more creative signature schemes for
> MyFamily ownership.  This would also be a satisfactory solution.
>
> I wonder if this kind of complexity would be worth it.
> Do we gain much over the current system by using a signature scheme?
> (Apart from making large families shorter and easier to administer, at the
> cost of making small families longer.)
>
> > In summary, my world would not end if MyFamily ceased to existwe'd
> simply use the ContactInfo for family membership.  Obviously family
> membership then becomes spoofable, but perhaps who cares?
>
> It makes some difference for fallback directories, where we use a
> combination of family, contact, and IP to work out which relays are more
> likely to go down at the same time.
>
> I also wonder about the impact on path selection and client security -
> even an honest operator can have their relays compromised or be compelled
> to provide information.
>
> Tim
>
>
> Tim Wilson-Brown (teor)
>
> teor2345 at gmail dot com
> PGP 968F094B
> ricochet:ekmygaiu4rzgsk6n
>
>
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] putting 'Nuke MyFamily' to vote (#6676)

[Virgil Griffith]

I'm not wholly in favor of keeping MyFamily in its current form.  In Roster
we simply need a way to identify when two relays are owned by the same
operator.  Worst comes to worst we could use the email address in the
ContactInfo, or some such.

There have been proposals to do more creative signature schemes for
MyFamily ownership.  This would also be a satisfactory solution.

In summary, my world would not end if MyFamily ceased to existwe'd
simply use the ContactInfo for family membership.  Obviously family
membership then becomes spoofable, but perhaps who cares?

-V

On Sunday, 27 March 2016, nusenu  wrote:

> One year after my last thread on that topic [0] I'd like to move forward
> on the question whether tor should have a MyFamily functionality or not,
> because it seems to be a blocker of prop242 (#5565) and it is clear that
> the current MyFamily design is not practical for many - given the amount
> of improper or undeclared families [6].
>
> prop 242 is also relevant in the context of Sibyls because if MyFamily
> becomes trivially easy for everyone to configure one might even start to
> use it to tell "good" and "bad" apart.
>
> If you have an opinion on that topic please reply.
>
> I tried to collect opinions on that from past threads and trac.
>
> When Nick asked "So, what do we think?" last year only people in favor
> of keeping it replied.
>
> In favor of keeping it:
> Nick [1]
> Teor [2]
> Virgil [3]
> Griffin [4]
> Moritz [5]
>
> In favor of nuking MyFamily:
> rransom
> anyone?
> Please speak up.
>
> Tools that use/display/process/depend on MyFamily:
> - tor-roster.org
> - onionoo
> - atlas
> - others?
>
> Can we close #6676 if no one is in favor of removing MyFamily?
> https://trac.torproject.org/projects/tor/ticket/6676
>
>
>
> [0] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html
> [1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008517.html
> [2] https://lists.torproject.org/pipermail/tor-dev/2015-March/008531.html
> [3] https://lists.torproject.org/pipermail/tor-dev/2015-March/008527.html
> [4] https://lists.torproject.org/pipermail/tor-dev/2015-March/008529.html
> [5] https://trac.torproject.org/projects/tor/ticket/6676#comment:8
> [6]
>
> https://raw.githubusercontent.com/nusenu/tor-network-observations/master/tor_families_master.txt
>
> https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Configuring Single Onion Services

[Virgil Griffith]

For whatever it's worth I never found the compile-time option for tor2web
mode to be offensive.

I remember Roger's original rebuttal against tor2web mode was, "Virgil, I'm
not going to make a 'Make Tor Go Faster Button' to be pressed by people who
don't know what they are doing."

I always thought the compile-time-flag or text warning was a good
compromise.

-V

On Friday, 8 April 2016, George Kadianakis  wrote:

> Tim Wilson-Brown - teor > writes:
>
> > [ text/plain ]
> > Hi All,
> >
> > I'm working on proposal 260's Rendezvous Single Onion Services in #17178.
> >
> > They are faster, because they have one hop between the service and the
> introduction and rendezvous points.
> > But this means that their location is easy to discover (non-anonymous).
> > So we want to come up with a design that makes it hard to configure a
> non-anonymous service by accident.
> >
> > Here's a cut-down version of an email I sent to tor-onions for feedback,
> for those who are on both lists:
> >
> > Nick's concern was that users could configure Single Onion Services
> without realising that it provides no server location anonymity.
> > I initially thought we could change the torrc option name to make this
> clear. ...
> > I now believe that trying to overload the name of a feature with
> warnings about its downsides was a mistake. …
> >
> > This would mean that Single Onion Service operators would include in
> their torrc:
> >
> > SingleOnionMode 1
> > HiddenServiceDir …
> > ...
> >
> > As a separate issue, I think there are two alternative designs that can
> prevent users from configuring the feature and then exposing their location
> unintentionally:
> >
> > Tor2WebMode requires users to add a compilation option:
> --enable-tor2web-mode
> > We could do this with Single Onion Services as well:
> --enable-single-onion-mode
> > If SingleOnionMode is configured without the compilation option, tor
> warns the user and refuses to start.
> > When it is configured, tor warns the user they're non-anonymous, then
> starts.
> > However, using a compilation option makes the feature harder to test.
> > And Tor2Web operators already don't like having to compile separate
> binaries.
> > It's likely Single Onion operators would feel similarly.
> >
> > Alternately, we could add a torrc option: NonAnonymousMode
> > If SingleOnionMode is configured without NonAnonymousMode, tor warns the
> user and refuses to start.
> > When it is configured, tor warns the user they're non-anonymous, then
> starts.
> >
> > I spoke with Nick on IRC and he's happy with either of these options.
> >
> > I'd like to proceed with the NonAnonymousMode torrc option, unless there
> are compelling reasons against that design.
> > I hope that this will allow us to get SingleOnionMode merged early in
> tor 0.2.9.
> >
>
> I think I like this approach more than complicating the torrc option name!
>
> Coming up with a warning message for people who forget to enable
> NonAnonymousMode seems easier than trying to fit that warning message in a
> torrc option name.
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Advice regarding Cloudflare

[Virgil Griffith]

On Sun, Apr 3, 2016 at 4:04 PM, Yawning Angel  wrote:
> Well, I did write an addon that just fetches content from archive.is
> whenever I get a Captcha.  Does that count?

That's cool Yawning.  Got a link to that?  I'd like to try it.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Is it possible to specify voluntary delays in my Tor client?

[Virgil Griffith]

I.e., if I want the extra resistance to traffic analysis that higher
latency connections provide, is there a way to specify that in my Tor
config?


-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is it possible to specify voluntary delays in my Tor client?

[Virgil Griffith]

I understand that the original Tor model is to set low-latency and
low-jitter as a constraint as to permit things like interactive
web-browsing etc.  And yes, I presume Tor will always have this as a
constraint.

I am asking if:
(1) There currently exists some way I can specify in my torrc to
sacrifice some of these in exchange for a little greater anonymity
protection (say I want to slowly leak a file, etc.)

(2) If not, how difficult would be it to shoe-horn this into the
current tor model?  In short, if it's not too difficult, I can look
into finding funding it.

-V

On Wed, Jan 20, 2016 at 1:37 PM, grarpamp <grarp...@gmail.com> wrote:
> On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith <i...@virgil.gr> wrote:
>> I.e., if I want the extra resistance to traffic analysis that higher latency
>> connections provide, is there a way to specify that in my Tor config?
>
> Higher latency, in and of itself, does not provide any resistance to
> traffic analysis.
>
> https://en.wikipedia.org/wiki/Latency_(engineering)
>
> Higher global jitter might help, but circuit orientation at
> guards and exits through to the clients seems to nullify that.
>
> https://en.wikipedia.org/wiki/Jitter
>
> For which an idea may to become packet switching, which
> is really no longer Tor.
>
> https://en.wikipedia.org/wiki/Packet_switching
>
> Link padding seems the next real step but I've not put enough
> reading to it, only have idea to read about. Nor do I yet review about
> Tor padding proposal as sufficient or not, sorry.
>
> As it is not the Tor original model design maybe some other
> network will take this analysis / padding issue up before then.
> I've no idea.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)

[Virgil Griffith]

In our quantifications of relay diversity, knowing the IP addresses that
traffic exits from is important. Ways to have this information correctly
reported would be very helpful.

-V
On Thu, 14 Jan 2016 at 03:01 grarpamp  wrote:

> On Wed, Jan 13, 2016 at 4:27 AM, coderman  wrote:
> >>> ... only question is who would have a
> >>> compelling use for separating outbound OR connections and outbound
> >>> Exit traffic, as per #17975?
> >>
> >> Bandwidth peering contracts preferential to push or eyeball traffic.
>
> > outbound bind address. Exit binding as distinct option might be
> > useful, yet no one has defined a reasonable scenario for such utility.
>
> another reason could be separating the exitIP as
> sacrificial on abuse complaint and/or set in a freeforall dmz,
> where orIP may more neutral and/or long term.
>
> don't know if anyone has deployed on any of these potential reasons.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Virgil Griffith]

Tom, to ensure I understand you clearly, is your argument that relays that
export only unencrypted shouldn't get the Exit Flag because
insecure/unecrypted traffic "isn't what Tor is intended for?" I want to be
sure that I'm fully understanding your proposal.

-V
On Wed, 6 Jan 2016 at 17:57 Moritz Bartl  wrote:

> On 01/05/2016 01:29 AM, Tom van der Woerdt wrote:
> >   communities on the internet. Other popular ports have been considered,
> >   such as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to
> be good
> >   candidates because of wide spread bruteforce attacks on these ports.
>
> Just as a data point, I don't see much scanning/abuse regarding SMTPS
> (465) or IMAPS (993).
>
> --
> Moritz Bartl
> https://www.torservers.net/
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Virgil Griffith]

I would argue that the existence of this longer policy discussion, with no
obvious solution, is why it behoves us to separate policy (as much as
possible) from Tor's core mechanism.

-V
On Wed, 6 Jan 2016 at 21:42 Peter Tonoli  wrote:

> Quoting Tim Wilson-Brown - teor :
> > If we ensure that Exits must pass some encrypted traffic, then
> > running an Exit is less attractive to an adversary.
>
> I'd argue that it's marginally less attractive. They still have the
> opportunity to inspect some unencrypted traffic.
>
> > And even adversaries contribute useful, secure bandwidth to the Tor
> Network.
>
> This could also potentially backfire: adversaries can create local
> (non-tor) policies to throttle encrypted exit traffic, while not
> throttling unencrypted traffic.
>
> Peter..
>
>
>
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Virgil Griffith]

> Other protocols (SSH, IMAP,
> POP3, SMTP) are indeed more popular but I feel that those less reflect
> the goals of the project, and they are certainly abused more.

I hear you that these are abused more.  But I personally think of Tor as a
mere mechanism than a mechanism+policy.  For example, should the command
"rm" refuse to remove a file that has the text in it that says "IMPORTANT!
DO NOT DELETE!"  Although obviously this is a well-intentioned feature,
presumably rm should not behave this way.  The rm command is a mechanism,
the policy for that mechanism judicious use is a wrapping around the
command itself.

One additional benefit of separating mechanism from policy is that it makes
policies more easily changeable.  Well-meaning people have disagreements on
policies, and policies invariably evolve.  Separating policies from the
core functionality is helpful to allow easier experimentation with
alternative policies.

Applying this here, I argue that the ports a relay makes available should
not impact whether they get the exit flag.  This is consistent with
treating Tor as a mechanism instead of applying top-down a policy for how
people are "supposed" to use it.

-V



On Wed, Jan 6, 2016 at 2:25 AM Tom van der Woerdt  wrote:

> Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
> >
> >> On 5 Jan 2016, at 19:33, Tom van der Woerdt  >> > wrote:
> >> ...
> >> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
> >>>
>  On 5 Jan 2016, at 11:29, Tom van der Woerdt   
>  > wrote:
>  ...
>  2.1. Exit flagging
> 
>  By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry,
>  Exit
>  flags can no longer be assigned to relays that exit only to
> unencrypted
>  ports.
> >>>
> >>> One consequence of this proposal is that relays that only exit to 443
> >>> and 6667 will lose the Exit flag.
> >>> But these relays do exit to an encrypted port, so this somewhat
> >>> contradicts the goal of the proposal:
> >>> "Exit flags can no longer be assigned to relays that exit only to
> >>> unencrypted ports."
> >>
> >> ...
> >>
> >> (tlcr: any relay that currently holds an Exit flag and allows exiting to
> >> 443 and 6667, but not 80 or 5222.)
> >>
> >> tiggersWeltTor1 Bandwidth=2600
> >> smallegyptrela01 Bandwidth=22
> >>
> >> These two relays will be impacted, indeed.
> >
> > Point taken!
> >
> > How many Exits would lose the Exit flag intentionally based on this
> change?
> > (That is, how many have 80 & 6667, but not 443?)
>
> If we change 6667 to 5222, this changes (where 0->1 means it will become
> an exit and 1->0 means it will no longer be one) :
>
>   FruityOatyTorexit Bandwidth=17700 0->1
>   Alice Bandwidth=25 0->1
>   tiggersWeltTor1 Bandwidth=3100 1->0
>   onionnetGOT01 Bandwidth=387 0->1
>   icubdw2o2xipsdc Bandwidth=137 1->0
>   miepernl Bandwidth=1420 1->0
>   ReservoirPi2016 Bandwidth=114 0->1
>   TORWeazel Bandwidth=98 0->1
>   HelloWorld Bandwidth=820 1->0
>   smallegyptrela01 Bandwidth=22 1->0
>   AnonNodeFin69 Bandwidth=80 0->1
>   Serveur Bandwidth=703 0->1
>   Biverse Bandwidth=779 0->1
>   comaTor1 Bandwidth=148 0->1
>   Unnamed Bandwidth=138 1->0
>
> Gained bw: 20034
> Lost bw: 5637
>
> Tom
>
>
> (source of this data: https://paste.debian.net/360256/)
>
>
> >
> >>>
> >>> Why not make the rule: "at least one of 80/6667, and at least one of
> >>> 443/5222".
> >>
> >> Also sounds good to me. I opted for the smallest possible change
> >> (6667->5222) but what you're suggesting lgtm.
> >>
> >>>
> >>> I am also concerned about the choice of XMMP "because the XMPP protocol
> >>> is slowly gaining popularity within the
> >>> communities on the internet".
> >>> Shouldn't we focus on secure protocols that are widely used right now?
> >>>
> >>> Alternately, we could add other widely used SSL ports in addition to
> >>> XMMP, and perhaps increase the rule to "at least two SSL ports".
> >>
> >> Imho the challenge is in finding port number(s) that accurately reflect
> >> what Tor is for, while also having a sufficiently large user base for it
> >> to be relevant. XMPP probably has more users than IRC, and is a good
> >> match for what I think Tor would consider important (communication).
> >> Also note that we now have Tor Messenger. Other protocols (SSH, IMAP,
> >> POP3, SMTP) are indeed more popular but I feel that those less reflect
> >> the goals of the project, and they are certainly abused more.
> >
> > 80/443 get us anonymous web browsing, primarily through Tor Browser
> > 6667/6697 get us anonymous messaging via IRC
> > (I don't know if 6697 is common enough to be worth changing for.)
> > 5222 get us anonymous messaging via Tor Messenger
> >
> > I can't think of any others right now.
> >
> > Tim
> >
> > Tim Wilson-Brown (teor)
> >
> > teor2345 at gmail dot com
> > PGP 968F094B
> >
> > teor at blah dot im
> > OTR CAD08081 9755866D 89E2A06F 

[tor-dev] Traffic correlation attacks on Hidden Services

[Virgil Griffith]

I've been looking into simple graph-theoretic metrics for Roster to
quantifying Tor's susceptibility to traffic correlation attacks, mostly
using BGPStream, https://bgpstream.caida.org/ .

All of the academic literature I've read talks about the risk to Tor users
of an AS being in the path between client <-> guard + exit <-> destination.

Questions:
(1) To ensure I'm not measuring the wrong thing, can someone be more
specific on the correlation attack scenario for Tor hidden services?

(2) Just guessing, but would be it be the same but replace "exit <->
destination" with: "HS server <-> HS guard" ?

(3) If yes to (2), the natural solution is simply to install a Tor relay on
the HS server itself so that there's no ASpath between the two?

Comments greatly appreciated.  I'm not an internet routing expert and I
want to ensure Roster is incentivizing the right things to harden the
network.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[Virgil Griffith]

On Mon, Nov 9, 2015 at 10:01 PM, isis  wrote:
>If you need some application to have the ability to associate your LinkedIn
>address with your relay, then write a program which uses (one of) your

For what it's worth, the LinkedIn reference was my attempt at humor to
add levity to otherwise usually dry material.  I concur that it would
be odd if someone put their LinkedIn in their relay's ExtraInfo
descriptor.

> G. "that it exit with error telling her torrc file is a likely culprit"…

For what it's worth, in the first draft of this the pronoun was male,
but I explicitly changed it to female (no personal pronouns are
mentioned anywhere else) because I wanted to be more gender-inclusive.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[Virgil Griffith]

> A. You still appear to be confusing the terms "torrc" and "extrainfo".

I recognize this error and will fix it.

> B. Do you mean for all extrainfo descriptors?

I support excluding Bridge relays for exactly the reasons you
mentioned.  My sole is to clean up the bitcoin addresses in the
ContactInfo field as well as allow relays to integrate with Roster
better as well as clean up the

> C. Why do we need 5KB of unparseable, unspecified, cruft in the descriptors?

> D. The extrainfo descriptors are not a message-passing channel for data for 
> other applications, nor should they be.

In Paris I asked Roger for a bitcoin field in the ExtraInfo descriptor
because currently Bitcoin addresses are polluting the ContactInfo, and
I'd like to clean that up.

Roger said he couldn't add a bitcoin field because if he made a
bitcoin field then everyone's pet project will ask him for special
ExtraInfo headers.  He proposed instead making an "x-" namespace where
people can scribble in for their pet projects.  This advice seemingly
conflicts with your (D).  In my defense, I was just following orders.


> E. "truncated"

   I say the OP does the truncation.  If someone modifies their Tor
client to create a broken or otherwise unparseable ExtraInfo
descriptor that is their choice, and my understanding is that this
patch does not increase anyone's ability to specify malformed
ExtraInfo descriptors.


> G. "that it exit with error telling her torrc file is a likely culprit"…

I aspire to be more mindful in my gender-inclusive language.


> H. "CustomValueChar as specified per RFC 2822"

Atagar suggested I use RFC 2822 as a template.


That's all I got really.  If someone has an alternative suggestion for
allowing people to specify things like Bitcoin addresses I'm all ears,
but this was the path I was explicitly placed on.  I will correct the
errors (A), (E), (G), (F).  I am all ears on how to fix (H).

-V

On Mon, Nov 9, 2015 at 10:01 PM, isis <i...@torproject.org> wrote:
> Virgil Griffith transcribed 10K bytes:
>> Yes I did.  Here's the modified proposal.
>>
>> Filename: ExtraRelayDescriptorFields.txt
>> Title: Adding X-namespace to extra-info descriptor for key:value pairs
>> Author: Virgil Griffith
>> Created: 2015-09-30
>> Status: Open
>>
>>
>> 1. Motivation
>> We wish to allow developers to build new applications atop relays. Towards
>> this end, we wish to add the ability for users to specify arbitrary new
>> key-value entries under the "X-" namespace to the extra-info descriptor.
>> The canonical applications for this are adding a bitcoin donation address,
>> networking of tor2web nodes, and display operator information on a
>> Roster[1] page.
>>
>>
>> 2. Proposal
>> Allow optional key-value lines in the relay's torrc file.
>>
>> The following would be added to section 2.1.2 of the dir-spec [2]
>> (Extra-info document format):
>>
>> 
>> "X-" CustomKey SP CustomValue NL
>>
>> CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_"
>> CustomKey = 1*32 CustomKeyChar
>>
>> CustomValueChar = atext / specials
>> CustomValue = 1*1024 CustomValueChar
>>
>> There can be multiple X-fields, for example...
>>
>> X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
>> X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
>> X-linkedin https://www.linkedin.com/in/virgilgr
>> X-keybase http://fncuwbiisyh6ak3i.onion/virgil
>> X-favoritequote Be excellent to each other.  Party on dudes!
>> X-foo bar
>>
>> The same CustomKey appearing more than once is disallowed.
>> Possible values for CustomValueChar as specified per RFC 2822
>> sections 3.2.1 and 3.2.4 [3].
>>
>> The sum size accounting for all such custom fields is truncated to 5
>> kilobytes.
>> 
>>
>> To mitigate the chance of a malformed torrc file, I additionally propose
>> that the relay descriptor be scanned and if it does not match the
>> specification, that it exit with error telling her torrc file is a likely
>> culprit.
>>
>> References
>> [1] http://tor-roster.org
>> [2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700
>> [3] https://www.ietf.org/rfc/rfc2822.txt
>
> Hello Virgil,
>
> Some feedback:
>
> A. You still appear to be confusing the terms "torrc" and "extrainfo".
>
>Or did you mean that there will be both X-Some-Crap torrc options and
>fields in the extrainfo 

Re: [tor-dev] Desired exit node diversity

[Virgil Griffith]

Instead of WOT, it seems more desirable, and better fit diversity, to have
both your best friends and worst enemies on the same circuit. Ergo,
minimizing chance of collaboration.

-V
On Mon, 26 Oct 2015 at 01:30 grarpamp  wrote:

> On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had:
> > I agree with Roger that ideally all relays can be exits (and since
> > we're being ideal, we'll assume that 'exit' means to every port). And
> > the network location distribution of relays by bandwidth is
> > proportional to both the client destination selection over time and
> > general Internet traffic over time, which match each other since we're
> > being ideal, and also matter since we're using an ideal trust-aware path
> > selection algorithm. And network wide route selection is such that
> > there is no congestion (generalizing Roger's assumption of infinite
> > exit capacity).
>
> Guessing that... assuming you can ship and calculate all the relay
> data / DHT / weights / KEX / circuits / preferences without
> bogging down your network or cpu...
>
> More relays being exits yields higher maximum possible path diversity.
> More relays being exits yields higher potential aggregate throughput
> between the network and clearnet.
> More exits yields broader more complete location overlay relavent to
> users (more relays yields more guards), datacenteres, and clearnet
> services (though there's as yet no attempt to exit near a service
> unless done manually).
>
> However when subject to global passive adversary tapping
> lots of the fiber, and you turn up more relays as exits (which
> are also non-exit relays by nature), you're adding lots more
> unused bandwidth over the same current consumption, leading
> to lots of unused quiet portions of the network.
> Which seems a greater potential for the adversary to "look, user
> just shot a unique traffic pattern completely through the quiet
> zone, gotcha".
> Whereas when the network links are full with clocked traffic
> (and fill traffic if there would otherwise be slack space) that
> observation attack is hardly as possible, to relavently impossible.
>
> If true, it seems to me adding more [non] exits should be pegged to
> some metrics and solicited on need / planning rather than turning
> up 6000 exits all at once.
>
> > In our ongoing work on trust-aware path selection, we assume a trust
> > distribution that will be the default used by a Tor client if another
> > distribution is not specified. (Most users will not have a reasoned
> > understanding of who they actually need to worry most about, and even
> > if they somehow got that right would not have a good handle how that
> > adversary's resources are distributed.)  We call this adversary "The
> > Man", who is equally likely to be everywhere (each AS) on the
> > network. For relay adversaries, we assume that standing up and running
> > a relay has costs so weight a bit to make relays that have been around
> > a long time slightly more likely to be trusted.
>
> tor-relays had talk of individual humans keyparty signing their relays
> and including that WOT along with other trust and meta metrics
> in the consensus or other queryable datastore that could be used
> by the user to select preferred relay sets in whichever sensible or
> silly ways suited them.
>
> An adversary standing up relays has costs.
> Adversaries standing their human agents in public, even if
> their undercover is maintained, has additional costs and risks.
>
> > You
> > would then be faced with the political nightmare of issuing default
> > policies that tells users they should route with a weighting that says
> > country foo has an x percent chance of being your adversary, but
> > country bar has a y percent chance. (Likewise also have similar
> > statements that substitute 'large multinational corp.', 'major
> > criminal organization', 'specific big government agency that is
> > getting all the press lately' etc.  for "country" in the last
> > sentence.)
>
> 
> In a sense this is like the original 'valid' flag, which you got
> by mailing me and having me manually approve your relay (and without
> which you would never be used as the entry or exit point in a circuit).
> Periodically I wonder if we should go back to a design like that, where
> users won't pick exit relays that don't have the "socially connected"
> badge. Then I opt against wanting it, since I worry that we'd lose
> exactly the kind of diversity we need most, by cutting out the relays
> whose operators we don't know.
>
> But both sides of that are just guessing. Let's find out!
> 
>
>
> These type of things may be better suited to a system
> where the users contribute their research and knowledge
> about the network into the network metadata db, and the
> users can query it to make their own decisions, follow
> other users prebuilt selection templates, or stick
> with the provided defaults.
> ___
> tor-dev mailing 

Re: [tor-dev] [tor-talk] Desired exit node diversity

[Virgil Griffith]

> Like Tails' friends, foes, and neutral HTP pools…
> "any member in a one pool should be unlikely to share logs (or other
identifying data),
> or to agree to send fake time information, with a member from the the
other pools"

This may be heretical, but I always thought this motivation above is a
plausible reason to have more "non-activist" types running Tor relays---we
just have too many friends, a few foes would be a welcome addition!

-V

On Wed, Oct 28, 2015 at 1:11 PM Tim Wilson-Brown - teor <teor2...@gmail.com>
wrote:

>
> > On 28 Oct 2015, at 14:31, Virgil Griffith <i...@virgil.gr> wrote:
> >
> > Instead of WOT, it seems more desirable, and better fit diversity, to
> have both your best friends and worst enemies on the same circuit. Ergo,
> minimizing chance of collaboration.
>
> Like Tails' friends, foes, and neutral HTP pools…
> "any member in a one pool should be unlikely to share logs (or other
> identifying data), or to agree to send fake time information, with a member
> from the the other pools"
> https://tails.boum.org/contribute/design/Time_syncing/#index4h2 <
> https://tails.boum.org/contribute/design/Time_syncing/#index4h2>
>
> T
>
> >
> > -V
> > On Mon, 26 Oct 2015 at 01:30 grarpamp <grarp...@gmail.com  grarp...@gmail.com>> wrote:
> > On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had:
> > > I agree with Roger that ideally all relays can be exits (and since
> > > we're being ideal, we'll assume that 'exit' means to every port). And
> > > the network location distribution of relays by bandwidth is
> > > proportional to both the client destination selection over time and
> > > general Internet traffic over time, which match each other since we're
> > > being ideal, and also matter since we're using an ideal trust-aware
> path
> > > selection algorithm. And network wide route selection is such that
> > > there is no congestion (generalizing Roger's assumption of infinite
> > > exit capacity).
> >
> > Guessing that... assuming you can ship and calculate all the relay
> > data / DHT / weights / KEX / circuits / preferences without
> > bogging down your network or cpu...
> >
> > More relays being exits yields higher maximum possible path diversity.
> > More relays being exits yields higher potential aggregate throughput
> > between the network and clearnet.
> > More exits yields broader more complete location overlay relavent to
> > users (more relays yields more guards), datacenteres, and clearnet
> > services (though there's as yet no attempt to exit near a service
> > unless done manually).
> >
> > However when subject to global passive adversary tapping
> > lots of the fiber, and you turn up more relays as exits (which
> > are also non-exit relays by nature), you're adding lots more
> > unused bandwidth over the same current consumption, leading
> > to lots of unused quiet portions of the network.
> > Which seems a greater potential for the adversary to "look, user
> > just shot a unique traffic pattern completely through the quiet
> > zone, gotcha".
> > Whereas when the network links are full with clocked traffic
> > (and fill traffic if there would otherwise be slack space) that
> > observation attack is hardly as possible, to relavently impossible.
> >
> > If true, it seems to me adding more [non] exits should be pegged to
> > some metrics and solicited on need / planning rather than turning
> > up 6000 exits all at once.
> >
> > > In our ongoing work on trust-aware path selection, we assume a trust
> > > distribution that will be the default used by a Tor client if another
> > > distribution is not specified. (Most users will not have a reasoned
> > > understanding of who they actually need to worry most about, and even
> > > if they somehow got that right would not have a good handle how that
> > > adversary's resources are distributed.)  We call this adversary "The
> > > Man", who is equally likely to be everywhere (each AS) on the
> > > network. For relay adversaries, we assume that standing up and running
> > > a relay has costs so weight a bit to make relays that have been around
> > > a long time slightly more likely to be trusted.
> >
> > tor-relays had talk of individual humans keyparty signing their relays
> > and including that WOT along with other trust and meta metrics
> > in the consensus or other queryable datastore that could be used
> > by the user to select preferred relay sets in whichever sensible or
> > silly ways suited t

[tor-dev] Time-to-first-byte on trac.torproject.org

[Virgil Griffith]

I started using Trac a bit more and the slowness is a little unpleasant.

Here are some stats:
http://www.webpagetest.org/result/151019_RW_387/

The time-to-first-byte is *painful* on both the first load as well as
reload.

Are there some ways we could improve this?  If it's sever-power I'm willing
to contribute to a fund for it, but my first thought is that more internal
caching needs to be turned on within Trac.  Common queries like the
frontpage shouldn't be this difficult.  But they are inherently this
difficult, then we should at least spread it out among multiple machines.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Getting meek covered by a CDN for free

[Virgil Griffith]

I met with some CDNs today and they have expressed interest in doing meek
for us.

Is there someone at Tor Project I can forward the CDNs to who are more
serious about hosting meek?

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: HTTP header distinguish TBB users

[Virgil Griffith]

> Are we still trying to hide TBB users in the Mozilla browser crowd?
My understanding of this, because we make the exit relays public, that the
answer is "no".  Correct me if I'm wrong.

> Are we making it even easier to identify and block TBB users?
Mildly so.  But if an operator wants to block TBB users they don't need to
have much trouble using ExitRelay list or the MaxMind anonymous proxy list.

For what it's worth we had a similar discussion in tor2web over whether to
add the "x-tor2web" request header.  We eventually decided to add it.

-V


On Sat, Oct 3, 2015 at 2:13 PM Tim Wilson-Brown - teor <teor2...@gmail.com>
wrote:

>
> On 3 Oct 2015, at 14:10, Virgil Griffith <i...@virgil.gr> wrote:
>
> (2) If we (Tor Project) is going to ask MaxMind to do something special to
> distinguish TBB users, it seems reasonable we should make the same effort.
> I know in the past it's been proposed for TBB to include a special HTTP
> header, e.g.,
>
> Tor-Browser-Bundle: true
>
> to distinguish TBB users.  If this header existed, I could detect it at
> the CDN-level and do the appropriate redirect.  Alternatively, We could do
> something equivalent with the "Via": HTTP header, but that seems overkill.
>
> Between these two options, I personally opt for (2) because it seems
> inappropriate to request MaxMind to help us do X when we have not done what
> we can do to achieve X.
>
> Q: Does anyone (especially Mike Perry) have any objections to (2)?  If
> not, I will write the proposal.
>
>
> I think this kind of tagging has security implications, but I’m not sure
> what the tradeoffs are.
>
> Are we still trying to hide TBB users in the Mozilla browser crowd?
> Are we making it even easier to identify and block TBB users?
>
> Tim
>
> Tim Wilson-Brown (teor)
>
> teor2345 at gmail dot com
> PGP 968F094B
>
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal: HTTP header distinguish TBB users

[Virgil Griffith]

Yesterday Lief compellingly argued that if a TBB user accidentally clicks
on a link to my tor2web proxy (onion.link), that they should be redirected
to the .onion address. It hadn't occurred before that a Tor user might
accidentally click a onion.link URL, but yes I completely concur and I told
Lief I would prioritize this and would owe him a Bitcoin if I didn't get
this implemented within a week.

Now the trouble starts. If the TBB user gets to the tor2web backend I check
if they're coming from an Exit relay and redirect them---all good.  But a
CDN (Fastly.com) sits in front of my backends and right now it's unclear
how to detect TBB at the CDN level.

Going over my CDN's documentation.  They do have the standard MaxMind
database for geo-IP.  So that's good.  But plugging in an exit-node IP#
merely reports as an "A1" for "Anonymous Proxy".  Unfortunately there are
many anonymous proxies other than Tor so that won't do.


There are two ways to solve this.

(1) For an given IP#, MaxMind reports numerous entries aside from the "A1"
for country code.  We could ask MaxMind to specify whatever else it knows
about the Anonymous Proxy in the other fields such as the "Location" or
"Organization" field.  So when plugging in a Tor exit relay it would return
something like:

{ "countrycode": "A1", "location": "Tor", "domain": "torproject.org" }

or some such.  This seems a reasonable request.  Do we know someone at
MaxMind to forward this request to?


(2) If we (Tor Project) is going to ask MaxMind to do something special to
distinguish TBB users, it seems reasonable we should make the same effort.
I know in the past it's been proposed for TBB to include a special HTTP
header, e.g.,

Tor-Browser-Bundle: true

to distinguish TBB users.  If this header existed, I could detect it at the
CDN-level and do the appropriate redirect.  Alternatively, We could do
something equivalent with the "Via": HTTP header, but that seems overkill.

Between these two options, I personally opt for (2) because it seems
inappropriate to request MaxMind to help us do X when we have not done what
we can do to achieve X.

Q: Does anyone (especially Mike Perry) have any objections to (2)?  If not,
I will write the proposal.


-V

P.S. Lief... even if we go at maximum speed, it looks like I'm going to owe
you that Bitcoin.  Email me your BTC address?  How embarrassing.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: HTTP header distinguish TBB users

[Virgil Griffith]

> TBB plugin: T2W-OE - tor2web onion everywhere.
> Fork HTTPS-E.
> Maintain list of known t2w's.
> Plugin update from tpo.
> Matching engine rewrites t2w URL's to onions in TBB before the fetch.

You are correct my good sir!  This is indeed the better way.  Thank you!  I
made a pull request to HTTPS-E for the requisite tor2web rules.

https://github.com/EFForg/https-everywhere/pull/3033

It's unclear to me how to make these rules only apply to the TBB version,
but judging by the version history of HTTPS-E they have a way of doing that.

Unless there's another specific issue, I consider the matter of Tor users
accidentally clicking links to Tor2web nodes solved.

-V

On Sat, Oct 3, 2015 at 8:29 PM grarpamp  wrote:

> > various wrote:
> > Yesterday Lief compellingly argued that if a TBB user accidentally
> clicks on
> > a link to my tor2web proxy (onion.link), that they should be redirected
> to
> > the .onion address. It hadn't occurred before that a Tor user might
> > accidentally click a onion.link URL
>
> TBB plugin: T2W-OE - tor2web onion everywhere.
> Fork HTTPS-E.
> Maintain list of known t2w's.
> Plugin update from tpo.
> Matching engine rewrites t2w URL's to onions in TBB before the fetch.
>
> > { "countrycode": "A1", "location": "Tor", "domain": "torproject.org" }
> > or some such.  This seems a reasonable request.  Do we know someone at
>
> They may not wish to if they want to return a single result per IP, and an
> IP could be running more than one proxy (tor, i2p/cjdns exit, vpngate,
> plain old vpn service, whatever), it's not generally possible to tell which
> proxy emitted traffic from said IP, nor is it reasonable to require tor
> exits
> operators to not participate in other networks.
>
> > Tor-Browser-Bundle: true
>
> Great for advertising statistical demand for anonymous access to
> clearnet web operators, bad for blocking.
>
> > Are we still trying to hide TBB users in the Mozilla browser crowd?
>
> TBB should conform to Mozilla. Though it's a unique header, currently
> unused by web operators, that's only for a while. If any such thing, it
> should
> be a toggle, default off. You don't want to be unique unless you have to,
> and it's unlikely even 1/3 of clearnet operators are programmatically
> exit-aware, with fewer programmed to block.
>
> > the "x-tor2web" request header. We eventually decided to add it.
>
> Which is fine because it doesn't disclose any bits about the user to
> clearnet, the disclosure to the onion is still anon and moot, and the
> user can go direct to the onion if the onion blocks t2w.
>
> > The CDN should forward the client IP address as X-Forwarded-For or
> > something?
>
> Other proxies, vpn's, chains, whatever between t2w and the exit may not do
> this.
>
> > If any sites do start blocking users based on the header (and not also
> based on IP)
> > it will push people into using a non-TBB browser to access Tor.
>
> Yep.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: HTTP header distinguish TBB users

[Virgil Griffith]

> That'll be half a BTC please, lol: 161JvwnowBsojF4rRcdjMRcztoLb7R1qkN

My pleasure.  You saved me half a BTC!

-V

On Sun, Oct 4, 2015 at 3:59 AM grarpamp <grarp...@gmail.com> wrote:

> On Sat, Oct 3, 2015 at 6:59 PM, Virgil Griffith <i...@virgil.gr> wrote:
> > You are correct my good sir!  This is indeed the better way.  Thank you!
>
> That'll be half a BTC please, lol: 161JvwnowBsojF4rRcdjMRcztoLb7R1qkN
>
> > It's unclear to me how to make these rules only apply to the TBB version,
> > but judging by the version history of HTTPS-E they have a way of doing
> that.
>
> A plugin may have a way of determining if it is plugged into TBB (tor)
> and acting accordingly. Else a separate T2W-OE plugin that takes
> precedence over HTTPS-E for t2w's. Or coordinate with HTTPS-E
> in that space.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[Virgil Griffith]

Filename: ExtraRelayDescriptorFields.txt
Title: Adding x-namespace to relay descriptor for key:value pairs
Author: Virgil Griffith
Created: 2015-09-30
Status: Open


1. Motivation
We wish to allow developers to build new applications atop relays. Towards
this end, we wish to add the ability for users to specify arbitrary new
key-value entries under the "X-" namespace to the router descriptor [1].
The canonical applications for this are adding a bitcoin donation address
and networking of tor2web nodes.


2. Proposal
Allow optional key-value lines in the relay's torrc file.  These lines will
be mirrored in the relay's descriptor which is then published in the
directory consensus.


The following would be added to section 2.1.2 of the dir-spec
(Extra-info document format):


"X-" CustomKey SP CustomValue NL

CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_"
CustomKey = 1*32 CustomKeyChar

CustomValueChar = atext / specials
CustomValue = 1*1024 CustomValueChar

Custom fields can appear multiple times, for example...

X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
X-favoritequote Be excellent to each other.  Party on dudes!
X-foo bar

If the same CustomKey appearing more than once is disallowed.
Possible values for CustomValueChar as specified per RFC 2822.

The sum size accounting for all such custom fields is truncated to 5
kilobytes.


To mitigate the chance of a malformed torrc file, I additionally propose
that the relay descriptor be scanned and if it does not match the
specification, that it exit with error telling her torrc file is a likely
culprit.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Adding x-namespace to relay descriptor for key:value pairs

[Virgil Griffith]

Yes I did.  Here's the modified proposal.

Filename: ExtraRelayDescriptorFields.txt
Title: Adding X-namespace to extra-info descriptor for key:value pairs
Author: Virgil Griffith
Created: 2015-09-30
Status: Open


1. Motivation
We wish to allow developers to build new applications atop relays. Towards
this end, we wish to add the ability for users to specify arbitrary new
key-value entries under the "X-" namespace to the extra-info descriptor.
The canonical applications for this are adding a bitcoin donation address,
networking of tor2web nodes, and display operator information on a
Roster[1] page.


2. Proposal
Allow optional key-value lines in the relay's torrc file.

The following would be added to section 2.1.2 of the dir-spec [2]
(Extra-info document format):


"X-" CustomKey SP CustomValue NL

CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_"
CustomKey = 1*32 CustomKeyChar

CustomValueChar = atext / specials
CustomValue = 1*1024 CustomValueChar

There can be multiple X-fields, for example...

X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
X-linkedin https://www.linkedin.com/in/virgilgr
X-keybase http://fncuwbiisyh6ak3i.onion/virgil
X-favoritequote Be excellent to each other.  Party on dudes!
X-foo bar

The same CustomKey appearing more than once is disallowed.
Possible values for CustomValueChar as specified per RFC 2822
sections 3.2.1 and 3.2.4 [3].

The sum size accounting for all such custom fields is truncated to 5
kilobytes.


To mitigate the chance of a malformed torrc file, I additionally propose
that the relay descriptor be scanned and if it does not match the
specification, that it exit with error telling her torrc file is a likely
culprit.

References
[1] http://tor-roster.org
[2] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n700
[3] https://www.ietf.org/rfc/rfc2822.txt



On Wed, Sep 30, 2015 at 12:49 PM Virgil Griffith <i...@virgil.gr> wrote:

> Filename: ExtraRelayDescriptorFields.txt
> Title: Adding x-namespace to relay descriptor for key:value pairs
> Author: Virgil Griffith
> Created: 2015-09-30
> Status: Open
>
>
> 1. Motivation
> We wish to allow developers to build new applications atop relays. Towards
> this end, we wish to add the ability for users to specify arbitrary new
> key-value entries under the "X-" namespace to the router descriptor [1].
> The canonical applications for this are adding a bitcoin donation address
> and networking of tor2web nodes.
>
>
> 2. Proposal
> Allow optional key-value lines in the relay's torrc file.  These lines
> will be mirrored in the relay's descriptor which is then published in the
> directory consensus.
>
>
> The following would be added to section 2.1.2 of the dir-spec
> (Extra-info document format):
>
> 
> "X-" CustomKey SP CustomValue NL
>
> CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_"
> CustomKey = 1*32 CustomKeyChar
>
> CustomValueChar = atext / specials
> CustomValue = 1*1024 CustomValueChar
>
> Custom fields can appear multiple times, for example...
>
> X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
> X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
> X-favoritequote Be excellent to each other.  Party on dudes!
> X-foo bar
>
> If the same CustomKey appearing more than once is disallowed.
> Possible values for CustomValueChar as specified per RFC 2822.
>
> The sum size accounting for all such custom fields is truncated to 5
> kilobytes.
> 
>
> To mitigate the chance of a malformed torrc file, I additionally propose
> that the relay descriptor be scanned and if it does not match the
> specification, that it exit with error telling her torrc file is a likely
> culprit.
>
> -V
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Desired exit node diversity

[Virgil Griffith]

Apologies for quick post.

If we want to a socially connected link, seems we can use the same
infrastructure for doing keysignings parties but we just use relay public
keys. That seems a nice distributed way of doing this.
On Thu, 24 Sep 2015 at 13:42 Virgil Griffith <i...@virgil.gr> wrote:

> Can we not use the argument "anonymity requires diverse company" on both
> sides? For whole rational actors it seems like this should work. Tor
> "exploits the military" into lending cover to activist groups, which they
> would presumably support.
>
> This may be too naive a view of the situation.
>
> Re: socially connected. That's interesting. I'll see what I can do. Chat
> more in Berlin.
>
> -V
> On Thu, 24 Sep 2015 at 13:19 Roger Dingledine <a...@mit.edu> wrote:
>
>> On Wed, Sep 23, 2015 at 06:18:58AM +, Virgil Griffith wrote:
>> > Exit nodes seem a nice place to start concretizing what's meant when we
>> say
>> > we want relay diversity. Comments immensely appreciated because as-is I
>> > don't know the answers to these questions.
>>
>> Hi Virgil,
>>
>> I've been pondering the opposite of this topic, after looking at the
>> recent tor-relays thread about some ISP not wanting to let somebody
>> host an exit relay because they figure a lot of the Tor network is
>> run by government agencies. My usual answer to that concern is "no, we
>> *know* the operators of more than half the capacity in the Tor network,
>> so this cannot be the case". And I think this is increasingly true in
>> the era of activist non-profits that run relays -- Germany's got one,
>> and so do the US, the Netherlands, Sweden, France, Luxembourg, etc etc.
>>
>> But it would be neat to have a mechanism for learning whether this is
>> actually true, and (whatever the current situation) how it's changing.
>>
>> The tie-in to Roster would be some sort of "socially connected" badge,
>> which your relay gets because you're sufficiently tied into the Tor
>> relay operator community.
>>
>> And then we'd have something concrete to point to for backing up, or
>> disputing, the claim that we know a significant fraction of the network.
>>
>> Of course, the details of when to assign the badge will be tricky and
>> critical: too loose and you undermine the trust in it (it only takes a
>> few "omg the kgb runs a relay and look it's got the badge" cases to make
>> the news), but too strict and you undercount the social connectedness.
>>
>> In a sense this is like the original 'valid' flag, which you got
>> by mailing me and having me manually approve your relay (and without
>> which you would never be used as the entry or exit point in a circuit).
>> Periodically I wonder if we should go back to a design like that, where
>> users won't pick exit relays that don't have the "socially connected"
>> badge. Then I opt against wanting it, since I worry that we'd lose
>> exactly the kind of diversity we need most, by cutting out the relays
>> whose operators we don't know.
>>
>> But both sides of that are just guessing. Let's find out!
>>
>> --Roger
>>
>> ___
>> tor-dev mailing list
>> tor-dev@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Desired exit node diversity

[Virgil Griffith]

> because "the right distribution" is a function of which adversary you're
> considering, and once you consider k adversaries at once, no single
> distribution will be optimal for all of them.)

Granted.  But since we're speaking idealizations, I say take that the
expected-value over the distributions weighted by the probability of each
adversary.  In application this would be a distribution that although
unlikely to be optimal against any specific adversary, it's has robust
hardness across a wide variety of adversaries.

Or, if that distribution is unclear, pick the distribution of exit-relay
with the highest minimum hardness.  This reminds me of the average-entropy
vs min-entropy question for quantifying anonymity.  I'd be content with
either solution, and in regards to Roster I'm not sure the difference will
matter much.  I am simply asking the more knowledgeable for their opinion
and recommendation.  Is there one?

-V



On Wed, Sep 23, 2015 at 2:47 PM Roger Dingledine <a...@mit.edu> wrote:

> On Wed, Sep 23, 2015 at 06:26:47AM +, Yawning Angel wrote:
> > On Wed, 23 Sep 2015 06:18:58 +
> > Virgil Griffith <i...@virgil.gr> wrote:
> > > * Would the number of exit nodes constitute exactly 1/3 of all Tor
> > > nodes? Would the total exit node bandwidth constitute 1/3 of all Tor
> > > bandwidth?
> >
> > No. There needs to be more interior bandwidth than externally facing
> > bandwidth since not all Tor traffic traverses through an Exit
> > (Directory queries, anything to do with HSes).
> >
> > The total Exit bandwidth required is always <= the total amount of Guard
> > + Bridge bandwidth, but I do not have HS utilization or Directory query
> > overhead figures to give an accurate representation of how much less.
>
> On the flip side, in *my* idealized Tor network, all of the relays are
> exit relays.
>
> If only 1/3 of all Tor relays are exit relays, then the diversity of
> possible exit points is much lower than if you could exit from all the
> relays. That lack of diversity would mean that it's easier for a relay
> adversary to operate or compromise relays to attack traffic, and it's
> easier for a network adversary to see more of the network than we'd like.
>
> (In an idealized Tor network, the claim about the network adversary
> might not actually be true. If you have exit relays in just the right
> locations, and capacity is infinite compared to demand, then the network
> adversary will learn the same amount whether the other relays are exit
> relays are not. But I think it is a stronger assumption to assume that we
> have exactly the right distribution of exit relay locations -- especially
> because "the right distribution" is a function of which adversary you're
> considering, and once you consider k adversaries at once, no single
> distribution will be optimal for all of them.)
>
> --Roger
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Desired exit node diversity

[Virgil Griffith]

Let's try a simple special case. In an idealized Tor network, what would
the distribution of exit nodes look like?

* Would each exit node have the same bandwidth? Or would there instead be
only one exit node per AS?

* Would the number of exit nodes constitute exactly 1/3 of all Tor nodes?
Would the total exit node bandwidth constitute 1/3 of all Tor bandwidth?

* Would their distribution of AS numbers match the distribution of AS
numbers of Tor clients? The distribution of Internet users?

Exit nodes seem a nice place to start concretizing what's meant when we say
we want relay diversity. Comments immensely appreciated because as-is I
don't know the answers to these questions.


-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Desired exit node diversity

[Virgil Griffith]

Can we not use the argument "anonymity requires diverse company" on both
sides? For whole rational actors it seems like this should work. Tor
"exploits the military" into lending cover to activist groups, which they
would presumably support.

This may be too naive a view of the situation.

Re: socially connected. That's interesting. I'll see what I can do. Chat
more in Berlin.

-V
On Thu, 24 Sep 2015 at 13:19 Roger Dingledine <a...@mit.edu> wrote:

> On Wed, Sep 23, 2015 at 06:18:58AM +, Virgil Griffith wrote:
> > Exit nodes seem a nice place to start concretizing what's meant when we
> say
> > we want relay diversity. Comments immensely appreciated because as-is I
> > don't know the answers to these questions.
>
> Hi Virgil,
>
> I've been pondering the opposite of this topic, after looking at the
> recent tor-relays thread about some ISP not wanting to let somebody
> host an exit relay because they figure a lot of the Tor network is
> run by government agencies. My usual answer to that concern is "no, we
> *know* the operators of more than half the capacity in the Tor network,
> so this cannot be the case". And I think this is increasingly true in
> the era of activist non-profits that run relays -- Germany's got one,
> and so do the US, the Netherlands, Sweden, France, Luxembourg, etc etc.
>
> But it would be neat to have a mechanism for learning whether this is
> actually true, and (whatever the current situation) how it's changing.
>
> The tie-in to Roster would be some sort of "socially connected" badge,
> which your relay gets because you're sufficiently tied into the Tor
> relay operator community.
>
> And then we'd have something concrete to point to for backing up, or
> disputing, the claim that we know a significant fraction of the network.
>
> Of course, the details of when to assign the badge will be tricky and
> critical: too loose and you undermine the trust in it (it only takes a
> few "omg the kgb runs a relay and look it's got the badge" cases to make
> the news), but too strict and you undercount the social connectedness.
>
> In a sense this is like the original 'valid' flag, which you got
> by mailing me and having me manually approve your relay (and without
> which you would never be used as the entry or exit point in a circuit).
> Periodically I wonder if we should go back to a design like that, where
> users won't pick exit relays that don't have the "socially connected"
> badge. Then I opt against wanting it, since I worry that we'd lose
> exactly the kind of diversity we need most, by cutting out the relays
> whose operators we don't know.
>
> But both sides of that are just guessing. Let's find out!
>
> --Roger
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays

[Virgil Griffith]

We'll remove it.

-V

On Mon, 14 Sep 2015 at 05:20 Tom van der Woerdt  wrote:

>
> On 13 Sep 2015, at 22:09, teor  wrote:
>
>
> On 13 Sep 2015, at 18:18, Sean Saito  wrote:
>
> >"No Self-Referencing Relays"
>
> >I'm not sure what exactly you mean by that but I assume it is a MyFamily
>
> >config where a relay includes his own fingerprint. Why does that hurt?
>
> >The unnecessary descriptor space/bw?
>
>
>
> This is something Virgil wanted because he thought self-connections were
> ugly.  If the
>
> penalizing of self-connections is found to be uglier than the
> self-connections themselves, we're
>
> both fine with removing it.
>
>
> Can this be downgraded to an informational message? (or eliminated
> entirely?)
>
> Penalties can be quite discouraging, particularly for minor configuration
> variants.
>
> Tim
>
>
> I agree, and this one in particular is important to some operators: by
> allowing a relay to specify itself in the family, one can just have a
> single configuration file for all relays in a family.
>
> Tom
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor's definition of 'median'

[Virgil Griffith]

Is there some implementation-specific reason not to use the standard
mathematical definition of median?  If not, I propose changing the
implementation to become it.

-V

On Tue, Aug 11, 2015 at 2:44 AM Nick Mathewson ni...@alum.mit.edu wrote:

 On Mon, Aug 10, 2015 at 1:11 PM, nusenu nus...@openmailbox.org wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
 
  Hi,
 
  https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028
 
  If 3 or more authorities provide a Measured= keyword for a router,
  the authorities produce a consensus containing a w Bandwidth=
  keyword equal to the median of the Measured= votes.
 
  a random sample from recent votes:
 
  grep 37.59.38.117 -A 3 *|grep Measured
  w Bandwidth=6869 Measured=7570
  w Bandwidth=6869 Measured=15500
  w Bandwidth=6869 Measured=18100
  w Bandwidth=6869 Measured=30500
 
  Tor says the median value is
  15500
 
  2015-08-10-16-00-00-consensus:
  w Bandwidth=15500
 
  but the median of these 4 values is actually:
  (18100+15500)/2 = 16800
  no?
 
  Has tor a different definition of 'median' and simply takes always the
  second ordered measurement vote out of 4 votes or is there a bug in
  the spec or implementation?

 There's one misplaced throwaway sentence in dir-spec.txt:

   All ties in computing medians are broken in favor of the smaller or
earlier item.
 

 We should bring this, and probably other things, into a definitions
 section earlier in dir-spec.txt.  Patches welcome. ;)

 --
 Nick
 ___
 tor-dev mailing list
 tor-dev@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor's definition of 'median'

[Virgil Griffith]

I mean the median.

From Wikipedia...

For example, if *a*  *b*  *c*, then the median of the list {*a*, *b*, *c*}
is *b*, and, if *a*  *b*  *c*  *d*, then the median of the list {*a*, *b*
, *c*, *d*} is the mean of *b* and *c*; i.e., it is (*b* + *c*) / 2.

-V

On Tue, Aug 11, 2015 at 9:29 PM John oneoft...@riseup.net wrote:

 I think you are confusing the median with the mean:

 https://en.wikipedia.org/wiki/Median
 https://en.wikipedia.org/wiki/Mean

 Taking the median instead of the mean can be beneficial in situations
 where you have larger outliers in your data, which typically affect the
 mean very much.

 -j

 Virgil Griffith:
  Is there some implementation-specific reason not to use the standard
  mathematical definition of median?  If not, I propose changing the
  implementation to become it.
 
  -V
 
  On Tue, Aug 11, 2015 at 2:44 AM Nick Mathewson ni...@alum.mit.edu
 wrote:
 
  On Mon, Aug 10, 2015 at 1:11 PM, nusenu nus...@openmailbox.org wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
 
  Hi,
 
  https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028
 
  If 3 or more authorities provide a Measured= keyword for a router,
  the authorities produce a consensus containing a w Bandwidth=
  keyword equal to the median of the Measured= votes.
 
  a random sample from recent votes:
 
  grep 37.59.38.117 -A 3 *|grep Measured
  w Bandwidth=6869 Measured=7570
  w Bandwidth=6869 Measured=15500
  w Bandwidth=6869 Measured=18100
  w Bandwidth=6869 Measured=30500
 
  Tor says the median value is
  15500
 
  2015-08-10-16-00-00-consensus:
  w Bandwidth=15500
 
  but the median of these 4 values is actually:
  (18100+15500)/2 = 16800
  no?
 
  Has tor a different definition of 'median' and simply takes always the
  second ordered measurement vote out of 4 votes or is there a bug in
  the spec or implementation?
 
  There's one misplaced throwaway sentence in dir-spec.txt:
 
All ties in computing medians are broken in favor of the smaller or
 earlier item.
  
 
  We should bring this, and probably other things, into a definitions
  section earlier in dir-spec.txt.  Patches welcome. ;)
 
  --
  Nick
  ___
  tor-dev mailing list
  tor-dev@lists.torproject.org
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
 
 
 
 
  ___
  tor-dev mailing list
  tor-dev@lists.torproject.org
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
 
 ___
 tor-dev mailing list
 tor-dev@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Roster introduction

[Virgil Griffith]

Probably not graphs. But the rest yes.

-V

On Wed, 29 Jul 2015 at 03:33 nusenu nus...@openmailbox.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hi,

 do you plan to add CW,CW fraction, measured bw (as soon as available
 via onionoo [1]), guard/exit probability, ... graphs to tor-roster?
 (similar to atlas but aggregated to the family)

 thanks


 [1] https://trac.torproject.org/projects/tor/ticket/16020
 -BEGIN PGP SIGNATURE-

 iQIcBAEBCgAGBQJVt9j4AAoJEFv7XvVCELh0wdYQAK5unbRdVqWHLC6GNBI9D4Aw
 hctgDsxt/cNiGYCJkxrq0VJnbs8wEo+ny7yG4wmG4O2iQiW02qIOPMbsCCjVxR5+
 Jv3ubxOuIjwhIcol31pWks6NoqWCQaY62Odam2YeJcR2aUVSaOzyYo90gMIuVMXY
 zEoDWLmWrvlOal8nUoA4fAhhPwR0TZR+JDBgnj9QC4FT25fRcHvbwCYZjmKu/Cfs
 4L+wPw8mx1OzTobViuHuxF891hdFnitJFZdvLks2D0/QaSFUZpgiSVhmutSJKAgu
 Mr3bUeYUF38VsSuvtP0aLpFAcYoUBQA1dBNxhVeaYgNa7mIHz8ADo1X6YM63+uzD
 uBqrtxVPQI0CjwjrcqeWpHixhAO8iLQfjTGTfB8TYRGvfqZ8whabTM9X82u1fZMn
 eFX6q1vXtOeHhVg4+DmfV259QH6UBSuDvH/C3lTjSgyAvDG+jFm9FW8ymSXDQcB3
 GmLuTybCZK5hvtXzUufQfOU5vl8Sl+JVxteBLfOjsci0UVmR1tE4/vj+jKDbbdke
 3SK/Se3VVXPXaUjw0sJ+pHLNCOSEgMu0G73DW7QAXCgw7hy+qWFR2ibgAKdYrQiU
 Y/yqiJfDVBKoIQwaKG7UwoTAHCorfW7c4jfSMfL9312GoPA57M+L+zHyKKiv1KWU
 xklNGefKSemyvLZUJnAr
 =Li7H
 -END PGP SIGNATURE-
 ___
 tor-dev mailing list
 tor-dev@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Roster introduction

[Virgil Griffith]

Hello everyone.

This is my first report on the Roster project and I wanted to give you
all an introduction what it is and where it's going.

I'm interested in seeing Tor grow.  Current work towards this is
tor2web and now Roster.  Roster is the rebranded continuation of the
Torati proposal which I first mentioned here:
https://lists.torproject.org/pipermail/tor-dev/2014-June/006975.html

In short the gist is to:
* Socially incentivize operators to run relays.
* Make the operator experience more compelling.
* Gamify operating a Tor relay.

The main difference between Roster and Globe/Atlas is that Roster
provides information at the level of *operators*, not individual
relays.  In Roster information is aggregated and metrics are summed
across all relays of a family.  The idea is that when you run a relay,
you generate nerd points and badges.  And then when people Google your
name/alias, they will see how many nerd points+badges you have and
they will be in awe of your epic geek-street-cred.

In addition to improving operator experience, there are proposals for
encouraging operators to do things Tor management like them to do such
as upgrading to the latest Tor version and/or probably setting up
their Families.  E.g., a badge for using the latest/recommended Tor
software.

That's the gist of it.

I will be spending most of my time on tor-relays@ and talking with
operators there.  So if you want to follow day-to-day stuff subscribe
there.

Main things accomplished so far:
* Setup the basic website at: http://www.tor-roster.org/

* I have an assistant whom I've taken under my wing.  His name is Sean
Saito saitos...@ymail.com.  He's a Computer Science student at
Yale-NUS here in Singapore.  He wishes to become more involved in The
Tor Project and this is his first Tor-related experience.

* We also have discussed with the tor-relays@ list candidate badges.
Are interested in additional badge proposals.
--- https://lists.torproject.org/pipermail/tor-relays/2015-June/007228.html

That's it so far.
-Virgil
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth

[Virgil Griffith]

One proposal I've liked is to socially discourage asymmetrical families by
giving them with bad badges on Roster.  If A says B is part of their family
but B doesn't reciprocate, A gets a penalty to their bandwidth points.

I think right now the proposals are to either:

(1) move forward using Observed Bandwidth for everything.  And when it gets
spoofed we must accept it and can talk about ways of improving it.

(2) use consensus weight as a proxy for real observed bandwidth.

Question: What is the downside (if any), of using Consensus Weight as the
sole measure of bandwidth points?

-V

On Thursday, July 2, 2015, l.m ter.one.lee...@hush.com wrote:

 The major problem with ticket 16276 is that it isn't a fix (as you seek
 here). It just moves the current implementation into the details document
 rather than being done in the node index. I don't think you *can* fix it as
 you seek. Bi-directionality isn't an enforceable property. The spec makes
 no guarantee. The internet makes no guarantee. You might as well remove the
 family property entirely than try to do what you suggest.

 What you propose isn't possible by the properties of tor's network. The
 best you can do is take a measurement and hope it applies to all views of
 the network. I made some comments alluding to this in 16276. I would
 happily work on the ticket if it actually presented a solution.

 Comments appreciated.
 --leeroy

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary

[Virgil Griffith]

This is my favorite paper on quantifying anonymity:

http://dimacs.rutgers.edu/Workshops/Anonymous/bagai.pdf

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] #15060: Decide the fate of MyFamily / prop242 better families

[Virgil Griffith]

 So, what do we think?  I'd say that MyFamily is likely to continue to

Virgil's gamification site needs a MyFamily, ergo I am in favor of
keeping MyFamily, whether it be in the current, prop242, or
alternative form.  Obviously the prop242 form is a much better
rendition of MyFamily, but unless we acquire an external entity that
is explicitly funding the gamification site I argue there are more
important things to be doing.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Suggestions for Projects

[Virgil Griffith]

If you're into android Orbot always comes to mind.

On Tuesday, December 16, 2014, Abhiram Chintangal 
abhiram.chintan...@gmail.com wrote:

 Hello,

 I am a student and I am thinking of getting myself more involved in the
 tor project over the winter break.

 Previously, I  worked briefly on the tor-weather rewrite project which
 eventually turned into an gsoc project in March 2014.

 Are there any projects that are in need of a volunteer? I am well versed
 in C, Python and Java (Android).

 Cheers!
 --
 Abhiram Chintangal


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] New documentation for Tor Metrics website

[Virgil Griffith]

At the top of the page,

 *And if you come across something that is missing here, please let us know.


For let us know, put an href to an email address/contact-info for
submitting ideas.


-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

[Virgil Griffith]

 - Opt-in HS indexing service

I offer to captain and lead development of this one.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Optimising Tor node selection probabilities

[Virgil Griffith]

Will a longer version of this paper be coming out, particularly one for
developers?

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scaling tor for a global population

[Virgil Griffith]

To avoid squashing the Tor network with all of these new clients, the
company would almost certainly have to run some big relays to help
compensate for the additional load.  Another proposal would be some sort of
incentive for running relays.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [GSoC] Consensus diffs - Sixth report

[Virgil Griffith]

Aside from future incorporations into Tor, do you currently have the
ability to have two consensus files and output the relays/data that have
changed?

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] I propose a kickstarter for Roger, Nick, or Paul to receive a free Tor tattoo of his choice

[Virgil Griffith]

e.g. https://imgur.com/sZUKADG

I will donate.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Revised spec for on adding extra torrc fields

[Virgil Griffith]

Damian and I worked through this off-list and this is the output of our
consensus.


URL:
https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.v3.txt

Any further revisions to be made before adding this to torspec?

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Torspec proposal for adding new X- fields to relay descriptor

[Virgil Griffith]

URL:
https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.txt

Fulltext below.  Comments appreciated.

-V
===

Filename: ExtraRelayDescriptorFields.txt
Title: Adding new X- fields to relay descriptor
Author: Virgil Griffith, Nick Mathewson
Created: 2014-06-03
Status: Open


1. Motivation
We wish to allow developers to build new applications atop relays. Towards
this
end, we wish to add the ability for users to specify arbitrary new key-value
entries under the X- namespace.


2. Proposal
Allow optional key-value lines in the relay's torrc file.  These lines will
be
mirrored in the relay's descriptor which is then published in the directory
consensus.

The format is:
X-key value


For example:
X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8
X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d
X-nameid virgil.gr
X-favoritequote Be excellent to each other.  Party on dudes!


The value field must be printable ASCII (characters 32-126).  The value must
not under any condition contain a newline.  The key may contain lowercase
ASCII letters (a-z), digits, underscore, or dash.  In regex, [-_0-9a-z].

There may need to be a maximum sum length of the X- entries.  This is
left to the developers.  I propose a maximum sum length of 5 kilobytes.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torspec proposal for adding new X- fields to relay descriptor

[Virgil Griffith]

Hi griffin!  Come join me at the Mozilla room and liberate this key from my
grasp!

In response to your concern, I modify the proposal that there be a torrc
schema which forbids unknown keys (unless they start with X-).  And the Tor
program rejects the relay if the torrc doesn't match the schema.

Secondarily, it makes sense to additionally verify that the generated relay
descriptor also matches the schema.

If either of these checks fail, then give the user an error to change their
torrc file.

-V

On Thursday, July 3, 2014, Griffin Boyce grif...@cryptolab.net wrote:

 In addition to explicitly forbidding newlines, perhaps it would be a good
 idea to either strip them entirely or ignore any value with a newline.
 --
 Sent from my tracking device. Please excuse brevity and cat photos.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] I have a group at internet archive that are, interested in buying a lot of OnionPi's

[Virgil Griffith]

It's already established that, for clients, onion-pi's are
discouraged---onion-pi wifi doesn't protect enough (I.e., at all) from
browser-based attacks.

Given that, The question is now, Are onion-pi's are good enough to be
useful relays?  Roger said no.  Is there a more informed opinion on this
matter---particularly from someone who has actually tried this?  Are there
any relays that are known to run on onion-pi?

If an onion-pi is insufficient for a useful Tor relay, what is the limiting
reagent?  What more does it need to be useful?

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] I have a group at internet archive that are interested in buying a lot of OnionPi's

[Virgil Griffith]

Roger et al, I'm interested in something like onion-pi to be a Tor relay.
 Is there something with enough COU to be viable?  I know nothing about
this embedded scene.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] I have a group at internet archive that are interested in buying a lot of OnionPi's

[Virgil Griffith]

What is the current state of the art on this, and if it is ready for
larger deployment want to buy about 50-100 of them.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal for improving social incentives for relay operators

[Virgil Griffith]

 Also, theconcept of naming authorities is about to be phased out [1], so

 better not build new services that rely on nicknames.


Karsten I love you.  Not only do you have fine ideas, you are the greatest
feedback provider in the world.


Agreed 100%.  Replace key-by-nickname with key-by-fingerprint.


Not crazy about having a a separate Torati name space, but meh, you do what
you have to.  Maybe make the nicknames a version 2.0 feature.  (Could
always make a namespace integration with google+!  Har.)


 Okay.  See Andrew's concerns about avoiding words having Tor in them.


I will find a name that doesn't explicitly invoke Tor.


-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [Tor2web] Proposal for improving social incentives for relay operators

[Virgil Griffith]

General remarks:
* I agree 100% with your Dec 2013 post.
* All data I seek to make available in Torati is available from
Onionoo.

The proposal is to interface to Torati is like ATLAS but keyed by Tor
nickname.
* However, where Atlas intends primarily to be a reference, Torati aims
to be social reputation
  incentivization for operators.  So you'd want Torati to be seen by
search engines using the user's
  nickname, e.g.,
  -- https://torati.torproject.org/TORTverLover
* A given nickname's contributions would be the sum across the relays
with that nickname.

Which in for TORTverLover would sum the stats across:
   *
https://atlas.torproject.org/#details/F2D3093388925780441433897F497797C5062B0B
   *
https://atlas.torproject.org/#details/A8541EA02D2BBE97086BC7EF44A67E8FDA0C75A9


To answer your questions:

 (The last link is a 404.)

Try: https://dl.dropboxusercontent.com/u/3308162/Iajya%202013.pdf
But the most important papers are the first two I linked.


 Why not make it entirely opt-in?  We could include a subscription
link in Weather's welcome messages that relay operators receive when
their relay first receives the Stable flag.

I greatly prefer opt-out over opt-in.  Even if a Torati operator is in
fact reputation-hungry, I don't want
the opt-in mechanic to encourage him/her to be seen as reputation
hungry.  Moreover, as ATLAS isn't
opt-in so I see no reason to deviate from that precedent as this is
really just a reverse-lookup version
of ATLAS.


 Where does the name Torati originate from?

 The name Torati is a Tor-ified version of digerati or
illuminati.  It's meant to convey something
 along the lines of Tor Ninja.  It's a positive term that one is
proud to call oneself.  The name was
 chosen as a component of the reputation social incentive.


-Virgil


On Tue, Jun 10, 2014 at 1:19 AM, Karsten Loesing kars...@torproject.org
wrote:

 [Attempting to move this discussion to tor-dev@ to avoid cross-posting;
 assuming my Reply-To: header won't get eaten by Mailman..]

 On 10/06/14 02:26, Virgil Griffith wrote:
  For a while I've been seeking to grow the Tor network in both size and
  goodput.  Towards this end, I've explored various avenues such as
  increasing user-awareness via tor2web.  More recently, I've been
 exploring
  financial incentives like TorCoin.
 
  Not wanting to strictly limit ourselves to financial incentives, I began
  reading the literature on incentivizing volunteers.  The most relevant
  papers I found are:
 
  *
 http://www-2.rotman.utoronto.ca/facbios/file/LMS2_ManSci-Paper-Final.pdf
   * http://pareto.uab.es/~prey/gneezy_254.pdf
  * https://dl.dropboxusercontent.com/u/3308162/Slonim%202013.pdf

 (The last link is a 404.)

  The most relevant of these papers (Lacetera 2013) cites the major
  motivations for volunteer labor are: pure altruism, warm glow,
 self-image,
  and reputation.  Upon reading this I realized TorCoin's technical
  interestingness had blinded me to much easier to leverage motivations of
  warm glow and reputation.
 
  I propose the following system for harnessing warm glow and
 reputation
  for Tor relay operators.  I am willing to fund this in its entirety.
 
  I propose establishing a subdomain on torproject.org giving each Tor
 relay
  operator (hereafter affectionately called Torati) his/her own page
 using
  the information her machines provide to the Tor Directory Consensus.  The
  fields to show on her Torati profile page would be things like:
  ContactInfo, PGP fingerprint, list of server nicknames, date the
 Directory
  Authorities first saw her contact info, etc.  You can also imagine a
  receiving special special recognition stars for operating an exit or
  bridge node.  Moreover, some bandwidth measurement like EigenSpeed or
  TorCoin gain traction, the Torati page could recognize contributors with
 by
  listing the sum total she has relayed to the Tor network.
 
  Naturally a node can opt-out of Torati recognition by setting a parameter
  in the torrc file.
 
  I argue this would be a cheap and easy way to motivate operators to
  volunteer more bandwidth for the Tor network.  As mentioned before, I am
  willing to fund this in its entirety.

 Hi Virgil,

 adding more/better incentives for people to run relays and bridges
 sounds like a great plan!

 What you describe sounds related to what I suggested last December on
 this list:

 https://lists.torproject.org/pipermail/tor-dev/2013-December/005948.html

  9. Provide relay comparison metrics in Onionoo.  We could define some
  simple metrics on the usefulness of a relay, like provided bandwidth or
  uptime, in comparison to other relays.  A possible statement from these
  metrics could be: your relay provides more bandwidth than 95% of relays
  in the network.  Similar to 8.  If Atlas [6] or Globe [8] or a
  yet-to-be-written Facebook application or a also-yet-to-be-written
  Twitter integration into Tor Weather (#10372) tell the world

[tor-dev] Proposal for improving social incentives for relay operators

[Virgil Griffith]

For a while I've been seeking to grow the Tor network in both size and
goodput.  Towards this end, I've explored various avenues such as
increasing user-awareness via tor2web.  More recently, I've been exploring
financial incentives like TorCoin.

Not wanting to strictly limit ourselves to financial incentives, I began
reading the literature on incentivizing volunteers.  The most relevant
papers I found are:

* http://www-2.rotman.utoronto.ca/facbios/file/LMS2_ManSci-Paper-Final.pdf
 * http://pareto.uab.es/~prey/gneezy_254.pdf
* https://dl.dropboxusercontent.com/u/3308162/Slonim%202013.pdf

The most relevant of these papers (Lacetera 2013) cites the major
motivations for volunteer labor are: pure altruism, warm glow, self-image,
and reputation.  Upon reading this I realized TorCoin's technical
interestingness had blinded me to much easier to leverage motivations of
warm glow and reputation.

I propose the following system for harnessing warm glow and reputation
for Tor relay operators.  I am willing to fund this in its entirety.

I propose establishing a subdomain on torproject.org giving each Tor relay
operator (hereafter affectionately called Torati) his/her own page using
the information her machines provide to the Tor Directory Consensus.  The
fields to show on her Torati profile page would be things like:
ContactInfo, PGP fingerprint, list of server nicknames, date the Directory
Authorities first saw her contact info, etc.  You can also imagine a
receiving special special recognition stars for operating an exit or
bridge node.  Moreover, some bandwidth measurement like EigenSpeed or
TorCoin gain traction, the Torati page could recognize contributors with by
listing the sum total she has relayed to the Tor network.

Naturally a node can opt-out of Torati recognition by setting a parameter
in the torrc file.

I argue this would be a cheap and easy way to motivate operators to
volunteer more bandwidth for the Tor network.  As mentioned before, I am
willing to fund this in its entirety.

-Virgil
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Has there been a security evaluation of the Hola routing software?

[Virgil Griffith]

www.hola.org


First impression it looks they aim to do the same things Tor does.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] updated two tor-spec proposals

[Virgil Griffith]

The URLs are the same.  They are:

(1) http://dl.dropbox.com/u/3308162/230-quicken-tor2web-mode.txt
(2) http://dl.dropbox.com/u/3308162/231-remittance-addresses.txt

I clarified them a bit and corrected the formatting.  Previously
people asked for more details such as what other specs will be
affected, there are the two references in 230 and in 231 there is no
interaction with existing specs.

If more changes need to be made please state so.  Otherwise I request
these be merged.

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Two torspec proposals

[Virgil Griffith]

I have two proposals to add to the torspec.git.  They are:

(1) http://dl.dropbox.com/u/3308162/230-quicken-tor2web-mode.txt
(2) http://dl.dropbox.com/u/3308162/231-remittance-addresses.txt


If someone with commit rights will add them that'd be lovely and we
can ignore the rest of this message.

If not, I request permission to commit to torspec.git.  My PGP is here
and we can discuss setting up a password, etc:
http://virgil.gr/1+Virgil_Griffith_pub.asc

-V
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Request for references for anonymous blocklisting (blacklisting)

[Virgil Griffith]

I'm putting together a proposal for adding anonymous blocklisting into the
Tor such that websites that block Tor can block single problematic users
instead of all Tor exit nodes.

Towards this end, I am looking for papers/prior work in this area to draw
from.  Pointers anyone?

Enjoyed the Iceland conference.  Thank you Roger for inviting me!  I aim to
be contributing to Tor more over the year.

-Virgil
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev