[tor-bugs] #15967 [Obfuscation/BridgeDB]: Separate BridgeDB's CAPTCHA into another service

[Tor Bug Tracker & Wiki]

#15967: Separate BridgeDB's CAPTCHA into another service
-------------------------------------------------+-------------------------
 Reporter:  isis                                 |          Owner:  isis
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:
Component:  Obfuscation/BridgeDB                 |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  bridgedb-https captcha tor-launcher  |  Actual Points:  2
  ooni-probe                                     |
Parent ID:                                       |         Points:  2
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorM
-------------------------------------------------+-------------------------

Comment (by mcs):

 Replying to [comment:4 isis]:
 > Couple things I realised I should do:
 >
 >  * There should be a 'version' field in every JSON thing so that we can
 add things later if we need to.

 That seems like a good idea even if we never end up changing it (with JSON
 you have a lot of flexibility to add fields as needed without necessarily
 bumping the version).

 >  * There should probably be a 'type' field in every JSON thing so that
 we know which part of the protocol it is.

 Seems like a good idea and having it may also aid in debugging the
 protocol.

 >  * The JSON in the `data` URL parameter should be en-/de- coded as URL-
 safe base64. (And it should probably just be in the body of the POST
 request?)

 I like the idea of putting the response in the POST request, but maybe it
 is small so it doesn't matter much? That raises another issue: Kathy and I
 don't know exactly what the response will look like. Will all of the
 CAPTCHAs be similar to the ones that are currently used by bridgedb?
 E.g.:
  https://bridges.torproject.org/bridges?transport=obfs4
 In any case, Tor Launcher will need to know how to present the image and
 what kind of response to ask the user for (e.g., text).

 Also, maybe the server should return the "Enter the characters from the
 image above" prompt text so the server has more flexibility about that
 form of the CAPTCHA (or is the in the challenge field?) One challenge is
 localization of the prompt. The server could respect the Accept-Language
 header, but that is not necessarily correct for Tor Browser due to our
 English language spoofing feature. Hmmm.

 > Also, in order to conform to [http://jsonapi.org/format/ the JSON API
 standard], I need to change the following things:
 > ...

 That looks like a lot of complexity, but it might be worthwhile if we are
 going to have more JSON messages. I assume we will, e.g., Tor Launcher
 will request bridges from moat via a JSON request.

 > Also, it just occurred to me that Tor Launcher should probably just talk
 to the moat server, which will talk to farfetchd. For the CAPTCHA stuff
 moat will just be passing things between Tor Launcher and farfetchd so the
 concerns about the API here are still relevant.

 I was going to ask about that... requesting a CAPTCHA and solving it is
 not useful unless the server that cares about the CAPTCHA is involved,
 right? Is there a document available that shows how the pieces will fit
 together? If not, we should create one.

 One more comment on your proposed API: Kathy and I would prefer error
 codes (numbers) rather than error strings, or at least a code plus a
 string. We will want to localize the errors that are displayed by Tor
 Launcher. It looks like the JSON API format includes this concept because
 error responses have a code as well as title and detail strings.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15967#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online