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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 isis):

 Replying to [comment:6 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

 Yes. They will be base64-encoded, jpeg images, 400px x 125px. (Is there
 something that would work better?)

 > 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.

 Hmmm. I am also not sure what to do here. I think probably, because TB's
 translation mechanics are quite different to BridgeDB's, it might be best
 to have TB create the string and localise it?

 >
 > > 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.

 Yeah, it's slightly complex, but it has everything we need and then we
 don't ever have to argue (also trying to think about the future when some
 router or VPN company wants to use this API) about who is doing things
 correctly.  (Also it's less work for me to just use the JSON-API spec
 rather than write and maintain my own, more minimal one.)

 > > 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.

 I created [https://github.com/isislovecruft/farfetchd/blob/master/API.rst
 a farfetchd API spec] and there's parts of it incorporated into the
 overall [https://github.com/isislovecruft/bridgedb/tree/fix/22871
 #accessing-the-moat-interface (draft) moat spec]. Let me know if you run
 across any more issues.

 > 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.

 Makes sense.  I'll rely on unique codes for different problems, that way
 you won't have to parse error strings.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15967#comment:9>
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