[tor-bugs] #15967 [Obfuscation/BridgeDB]: Separate BridgeDB's CAPTCHA into another service
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Sep 12 21:54:08 UTC 2017
#15967: Separate BridgeDB's CAPTCHA into another service
Reporter: isis | Owner: isis
Type: enhancement | Status:
Priority: Medium | Milestone:
Component: Obfuscation/BridgeDB | Version:
Severity: Normal | Resolution:
Keywords: bridgedb-https captcha tor-launcher | Actual Points: 2
Parent ID: | Points: 2
Reviewer: | Sponsor:
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
> > * 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
> 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?
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
#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
More information about the tor-bugs