[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

#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
         bridges@xxxxxxxxxxxxxx;
       * "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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs