-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Could we perhaps expand the contact information field in some way? One thing I was pondering a while ago was a social contact, not just an email address. I raised a very brief point about this with Virgil in Paris last year, but I think I made it very poorly at the time as I just come up with it on the spot.
To assign an email address is good for email communications and using PGP and so forth, but also allowing another handle such as a Twitter username would be a way to create further credibility of diversity. For example, my following on Twitter is quite diverse and it would be hard to argue I was a government proxy or so on. If many operators have Twitter handles where the information and identity is public anyway, having a second option to tie into those social parameters would be more transparent in the people running those relays if they chose to be. For example, I have no problem in being open on some of the projects I am working on, and I'm sure moving into a social sphere could have a positive effect on Tor in general in terms of trust.
For example, let's say the contact box lacks an email, we could see if there was a way for reaching out to people via Twitter to let them know a relay is outdated instead of private email reminders.
Anyway I am rambling on a bit there, but my point is getting people to use not just email, but also tie into a twitter account or something of that nature would make it clearer that Tor is not run almost exclusively by the military or whatever, since that kind of open data with aliases and Twitter feeds connected to the relay ownership is researchable if people, like Transparency Toolkit, wanted to "check us out" so to speak. To verify the data, we could make Roster have a small verification step, just a "tweet this code to verify this is your account" and then Roster can store the URL to this tweet to maintain an independent proof that alias controls which relay, similar to how Keybase does it.
T
On 24/09/2015 06:18, Roger Dingledine wrote:
On Wed, Sep 23, 2015 at 06:18:58AM +0000, 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