Opened 7 years ago

Last modified 9 months ago

#7106 new project

Write "how to be nice to the Tor network" spec

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: SponsorZ tor-client tor-spec documentation wiki intro
Cc: cass Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In talking to Jake, I realized that there are still some people who expect jtor to be a workable Tor client one day. In fact, we've even been writing some funding proposals that make this assumption.

One of the main issues we're going to have with an alternate Tor client is that while it may follow our network specs, it will have different observable behavior than the mainline Tor client.

First, this different behavior will make users partitionable. Fine, we can accept that. But we should finish writing path-spec.txt so authors of other clients can have at least a chance of doing things the way "real" Tor does.

Second, it's easy to make client-side decisions that harm the Tor network. For examples, you can hold your TLS connections open too long, or do too many TLS connections, or make circuits too often, or ask the directory authorities for everything. We need to write up a spec to clarify how well-behaving Tor clients should do things. Maybe that means we write up some principles along the way, or maybe we just identify every design point that matters and say what to do for each of them.

Child Tickets

Change History (9)

comment:1 Changed 7 years ago by ioerror

Indeed - if we have a spec for a tor client - even a limited on that merely exits the network (ie: no HS support at all) - we should be able to tell a person the spec and if they implemented it, we wouldn't be upset.

I don't totally agree that they will instantly be partitionable at all times. Perhaps they will be distinguishable from the C client on the path between the client and the the first hop? That seems to be the rub of a badly written spec though; if we set specific bytes in the handshake, we should spec that out, no? Once they are inside the network, I feel like the spec is not going to create a distinguisher that a middle or exit relay will notice.

comment:2 Changed 7 years ago by nickm

Keywords: tor-spec added; spec removed

Bulk-replacing "spec" and "torspec" keywords with "tor-spec".

comment:3 Changed 3 years ago by cass

Cc: cass added
Severity: Normal

This ticket is tagged SponsorZ, but it looks like progress stalled four years ago. Is this still an active issue that needs funding?

comment:4 Changed 3 years ago by nickm

I think this could use funding -- especially as part of an initiative to support or develop alternative tor implementations.

comment:5 Changed 3 years ago by arma

I agree with Nick that this is a great topic to work on. First it would help for alternative Tor implementations, but second it would bolster our habits of documenting and specifying our assumptions (we're already known for trying to be detailed and open and transparent, and this would be a great further step), and third I bet we would uncover some surprises that would make us think harder about ways to improve our design.

That said, this is the sort of topic that only a few people can do most usefully (e.g. Nick and me), since "think about all the assumptions you made while designing those parts of Tor, and try to write them down" isn't something a new developer can pick up and do by herself. So we should think carefully about the timing of a funding proposal for this one, so we don't fall into the trap of having funding for three Nicks and being surprised and sad that we only have one Nick.

comment:6 Changed 3 years ago by cypherpunks

"how to be nice to the Tor network"

lurk and surf

comment:7 Changed 3 years ago by nickm

Keywords: documentation wiki intro added

comment:8 Changed 2 years ago by arma

If we're smart, we'll do some of this work during the Rust transition anyway, since "remember why you built it that way, and explain that to the developer who's reimplementing it" is much of the way to "and document it".

Bonus points if, as we're doing it, we figure out some sort of structured way to capture these past insights in a way that is easily accessible for future developers.

comment:9 Changed 9 months ago by emmapeel

Is this ticket maybe meant for the community portal?

Note: See TracTickets for help on using tickets.