#18329: Let bridges indicate when they don't want BridgeDB to distribute their address ------------------------------+------------------------------------ Reporter: karsten | Owner: Type: enhancement | Status: needs_revision Priority: Medium | Milestone: Tor: 0.3.1.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-bridge, stem | Actual Points: Parent ID: | Points: .2 remaining Reviewer: nickm | Sponsor: ------------------------------+------------------------------------ Changes (by isis):
* cc: catalyst (removed) Comment: Replying to [comment:21 arma]: > […] > > I don't think it would solve much to use numbers, and I think it would indeed hurt the usability. That's fair; you've got me convinced that the numbers thing would be bad usability-wise. However, I'm still against "any bytes, any length, yolo." > The BridgeDB behavior can be very simple: if the field is there and bridgedb recognizes the value in the field, do the right thing with it, else if the field is there and bridgedb doesn't recognize it, don't distribute that bridge. Why would we waste bandwidth passing around descriptors with junk in them? Why not just filter the junk during descriptor creation? > Nick, what did you mean by "with Tor restricted to only accept recognized names if they appear in torrc"? You're hoping that we teach Tor more about the possible values of the field, and that it says something like "nope, never heard of that one, you can't set it" for ones it doesn't know about? Does that mean that people running Tor on (say) version 0.3.1.x will need to upgrade in order to list a name that we started using while (say) Tor 0.3.2.x was current? Why would we do that? Not to speak for Nick, but I think he meant just as you described: tor will say, "If you try to set a value which isn't in the list of things I recognise, I'm going to not include it in your descriptor." To make this simpler moving forward, the whitelist should currently include the following recognised values: `none`, `any`, `https`, `email`, `moat`, and `hyphae`. The default is `any`. This covers all current distributors, and the two which are planned for this year. (`moat` is the new distributor which sends Tor Launcher a CAPTCHA via a meek channel, and essentially acts exactly like the `https` distributor, but in XUL rather than HTML, in Tor Launcher. `hyphae` is the social distributor mentioned in #7520 and [https://patternsinthevoid.net/hyphae detailed here].) If we need to add a new distributor in the future — which I don't expect — you're correct that we'll need to get it added to tor's distributor whitelist. This is solvable by opening a ticket to get the new name added to the list, before starting work to build the distributor; this way, the name is likely recognised by the time the distributor is deployed. > I agree with Damian that we could be a bit clearer on the torspec side. I think what dgoulet was going for was the same spec as the Contact field has. From Tor's perspective, it is essentially an "anything goes" string. We could change it to say "set of 'key and optional value' fields" or something if we liked, but I think the only effect of trying to constrain it here will be producing bugs in stem later if we decide to change it. Damian, what would you like to see the spec for the Contact field look like? Then we can use that here too. Here's draft text describing the torrc option: {{{ "bridge-distribution-request" SP method NL [At most once] Each "method" describes how a Bridge address is distributed by BridgeDB. Recognized methods are: "none", "any", "https", "email", "moat", "hyphae". If set to "none", BridgeDB will avoid distributing your bridge address. If set to "any", BridgeDB will choose how to distribute your bridge address. Choosing any of the other methods will tell BridgeDB to distribute your bridge via a specific method: * "https" specifies distribution via the web interface at https://bridges.torproject.org; * "email" specifies distribution via the email autoresponder at brid...@torproject.org; * "moat" specifies distribution via an interactive menu inside Tor Browser; and * "hyphae" specifies distribution via a cryptographically-secure, invitation-based system. (Default: "any") }}} Damian, does that look okay from Stem's point of view? (Also, does this text make enough sense to the type of bridge operator who wants to micromanage their bridge?) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18329#comment:29> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs