Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
* Nick Mathewson: > I'd suggest that we should allow UTF-8 for values, at least. Indeed, that should work. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On Mon, Jul 27, 2020 at 2:05 PM nusenu wrote: > > >> In section "Defined fields" you write: > >> > >> Non-ASCII characters are not supported. > >> > >> I'm not sure if this applies only to keys or also to values? With the > >> availability of IDN (https://unicode.org/faq/idn.html) in email > >> addresses, supporting only US-ASCII values is too limited. > > > > I'd suggest that we should allow UTF-8 for values, at least. It looks > > like we're standardizing on UTF-8 as our character encoding for > > directory documents in Proposal 285. > > The state of prop-285 (open) was actually the reason why I did not put UTF-8 > into the CIISS :) Oops! Actually, that proposal should be "Accepted". We've gotten behind in labelling them. There's a ticket to label them right at https://gitlab.torproject.org/tpo/core/torspec/-/issues/1 > Is prop-285 already implemented in tor? Partially. Directory authorities reject anything that isn't UTF-8, in dirserv_add_multiple_descriptors(). > In that case I'm happy to add UTF-8 as recommended. cheers, -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
>> In section "Defined fields" you write: >> >> Non-ASCII characters are not supported. >> >> I'm not sure if this applies only to keys or also to values? With the >> availability of IDN (https://unicode.org/faq/idn.html) in email >> addresses, supporting only US-ASCII values is too limited. > > I'd suggest that we should allow UTF-8 for values, at least. It looks > like we're standardizing on UTF-8 as our character encoding for > directory documents in Proposal 285. The state of prop-285 (open) was actually the reason why I did not put UTF-8 into the CIISS :) Is prop-285 already implemented in tor? In that case I'm happy to add UTF-8 as recommended. -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On Fri, Jul 24, 2020 at 9:08 PM Ralph Seichter wrote: > > * nusenu: > > > https://github.com/nusenu/ContactInfo-Information-Sharing-Specification > > This is an effort that started in 2017 as you can see on github. > > In section "Defined fields" you write: > > Non-ASCII characters are not supported. > > I'm not sure if this applies only to keys or also to values? With the > availability of IDN (https://unicode.org/faq/idn.html) in email > addresses, supporting only US-ASCII values is too limited. I'd suggest that we should allow UTF-8 for values, at least. It looks like we're standardizing on UTF-8 as our character encoding for directory documents in Proposal 285. cheers, -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On 21.07.2020 19:16, nusenu wrote: keybase Much of this list is verified by keybase. ;-) https://keybase.io/boldsuck Keybase was purchased from Zoom. Some may want to use https://keys.pub/ instead. bitcoin zcash Zcash? If privacy coin then Monero. You can create an openalias for your looong BTC and XMR addresses. My: don...@for-privacy.net or donate.for-privacy.net -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On 21/07/20 18:16, nusenu wrote: Hi, I'm happy to finally announce version 1 of the ContactInfo Information Sharing Specification: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github. ... regards, nusenu Hi Nunsenu Firstly, thank you for taking the time to look at the issue of malicious relay operators and come up with some potential approaches for addressing it. If I understand correctly your objective is to increase the level of effort required to run a relay, at least when it comes to the larger relays. I assume that you assume that if more effort is required then malicious relay operators will shut down and go elsewhere? I do not feel the proposed verification measures will make a malicious relay operators life sufficiently more difficult unfortunately. Malicious relay operators already expend relatively large amounts of money and presumably effort to do their thing; the example you gave initially talked about a potentially malicious operator providing up to 23% of exit capacity - that must be a very expensive already surely? I can't help but feel that the issue of malicious operators could perhaps be better addressed by 1) Having a valid email contact address for any given relay as you already suggest; and 2) Having each operator join this mailing-list (using the above email address) and introduce, anonymously or otherwise, themselves and their relay(s). To have either the guard or exit flags on your relay you would need to complete the aforementioned 2 steps. In cases where there are concerns over a relay or set of relays then there would be a transparent and public forum where those concerns can be both raised and (hopefully) addressed, i.e. this mailing list. I get that it is not as interesting as a more technical approach but IMHO it would be more effective and could be implemented almost immediately and is actually not that easy to game compared to technical solutions. Anyway these are just my thoughts. Thanks again for taking the time to look at the problem. yours M Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
> I'm also fine with making it optional in the upcoming version 2 > to lower the barrier for adoption. My goal is not to make contact info optional. I do understand value of such information. The problem is choosing one specific means of communication as mandatory, instead of letting the operators choose the one that is most convenient to them. My primary gripe with email is not my privacy. I decided to remove it from my ContactInfo upon noticing that I skim over the messages and discard them in bulk as spam. At this point reaching me through email became unlikely: I would probably delete the message. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
* nusenu: > https://github.com/nusenu/ContactInfo-Information-Sharing-Specification > This is an effort that started in 2017 as you can see on github. In section "Defined fields" you write: Non-ASCII characters are not supported. I'm not sure if this applies only to keys or also to values? With the availability of IDN (https://unicode.org/faq/idn.html) in email addresses, supporting only US-ASCII values is too limited. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
Roman Mamedov: > On Tue, 21 Jul 2020 20:17:24 +0200 > nusenu wrote: > >>> What is the advantage over the torrc config value "MyFamily" ? >> >> MyFamily is somewhat orthogonal to the idea behind the verifyurl field. > > Still not getting what advantage do you propose to ones who choose to also > maintain the latter. > > It reads like the main purpose of "verifyurl" is to authorize "operatorurl", > but even as right now, if there's the same URL across all relays in a > consistent MyFamily, what additional authorization does this need and for > whom? Lets say someone sets up a bunch of relays and claims to be the EFF, The Torproject or any other entity they choose. This creates a link between the relay and the entity: (1) relay -> entity The verifyurl gives everyone, for example users of atlas.torproject.org the possibility to verify what they see. verifyurl create a link in the opposite direction: (2) entity -> relay (1) + (2) results in a bidirectional link which can not easily be made up. >> MyFamily has an impact on path selection, ContactInfo/verifyurl has not. > > Any legitimate example where you would want to claim a fleet of relays as your > own, but NOT want that to affect path selection? just to clarify: verifyurl is not trying to replace MyFamily. >> verifyurl is used to establish a bidirectional verification of the >> operatorurl. >> >> So if someone sets up a relay claiming to be torservers.net >> verifyurl can be used to detect that automatically if torservers.net sets >> verifyurl in their ContactInfo. > > Same already possible with MyFamily, if all other relays do not include that > one in their family, it can be assumed to be a "fake". MyFamily is used to link relay fingerprints. MyFamily alone does not provide any direct way to verify ContactInfo claims. You are assuming that there are other relays. If there are no other relays they can not be used to see the missing MyFamily link between the fake and real relays. kind regards, nusenu -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On Tue, 21 Jul 2020 20:17:24 +0200 nusenu wrote: > > What is the advantage over the torrc config value "MyFamily" ? > > MyFamily is somewhat orthogonal to the idea behind the verifyurl field. Still not getting what advantage do you propose to ones who choose to also maintain the latter. It reads like the main purpose of "verifyurl" is to authorize "operatorurl", but even as right now, if there's the same URL across all relays in a consistent MyFamily, what additional authorization does this need and for whom? > MyFamily has an impact on path selection, ContactInfo/verifyurl has not. Any legitimate example where you would want to claim a fleet of relays as your own, but NOT want that to affect path selection? > verifyurl is used to establish a bidirectional verification of the > operatorurl. > > So if someone sets up a relay claiming to be torservers.net > verifyurl can be used to detect that automatically if torservers.net sets > verifyurl in their ContactInfo. Same already possible with MyFamily, if all other relays do not include that one in their family, it can be assumed to be a "fake". -- With respect, Roman ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
Thank you for your feedback. mpan: > Can’t providing *any* contact info be > obligatory? What’s the point of making specifically the email address > required? What are benefits of having it *over other contact info*? I'd argue that email is the most accessible? The Tor Project used to use email as a communication channel when trying to reach operators about relay issues. I'm also fine with making it optional in the upcoming version 2 to lower the barrier for adoption. For example I find your ContactInfo string still valuable even though you do not provide the email field. kind regards, nusenu -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
mpan a écrit : > - Increasing contact? No. > I was offering an email address for some time and the only > experience was no single message from a human actually contacting > me about Tor. Everything was only spam. Suggesting address rotation > or antispam filters is merely an attempt to dismiss the issue, > not an answer to it. - Increasing contact? Yes. I offer a valid email address on my relays, because if there is any trouble with them I would like to be noticed quickly. There was also when torproject guys contacted me about fallback directory. How they could contact me if there wasn't address in ContactInfo ? If I don't put email address in ContactInfo, well, feel free to get reverse DNS of my relay (which is not an exit node), then go on my awesome website (thanks rDNS), then go on the "Contact Me" webpage, then finally get the valid address... No, that's too slow, that's not possible. IMHO, email is required. It is not about "tracking tor node operators", or "are you a trusted tor node operator with 2FA". It is about what happens if your node is doing sh*t because of mistake in config. Best regards, Casper -- Clé GPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
Great job, except one thing. Can’t providing *any* contact info be obligatory? What’s the point of making specifically the email address required? What are benefits of having it *over other contact info*? - Automatic verification of some kind? No. That would require client-side system coupled with email accounts. - Limiting abuse by requiring an email? No. Emails are cheap. Much cheaper than e.g. obtaining a domain and having some specific DNS entry or web page provided. That at least costs some money and confirms that the operator has control over the domain. - Increasing contact? No. I was offering an email address for some time and the only experience was no single message from a human actually contacting me about Tor. Everything was only spam. Suggesting address rotation or antispam filters is merely an attempt to dismiss the issue, not an answer to it. I see it as putting more burden on operator for no good reason and making yet another service require an easily abuseable information to be released. I’m aware of of benefits of email (open, “everyone” uses it) and downsides of other options (limited access, abusive or poorly designed websites), but are those really the argument for making this specific information trivially harvestable? As long as this is optional, it’s not a huge problem. But I do not believe in ignoring stuff simply because temporarily it does not affect me personally. mpan signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
Toralf Förster: > On 7/21/20 7:16 PM, nusenu wrote: >> verifyurl > > What is the advantage over the torrc config value "MyFamily" ? MyFamily is somewhat orthogonal to the idea behind the verifyurl field. MyFamily has an impact on path selection, ContactInfo/verifyurl has not. verifyurl is used to establish a bidirectional verification of the operatorurl. So if someone sets up a relay claiming to be torservers.net verifyurl can be used to detect that automatically if torservers.net sets verifyurl in their ContactInfo. -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On 7/21/20 7:16 PM, nusenu wrote: > verifyurl What is the advantage over the torrc config value "MyFamily" ? -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
