[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_review
 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):

 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.
  * There should probably be a 'type' field in every JSON thing so that we
 know which part of the protocol it is.
  * 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?)

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

  * The content-type apparently needs to be `application/vnd.api+json` (not
 `application/json`).
  * "Servers MUST respond with a 415 Unsupported Media Type status code if
 a request specifies the header Content-Type: application/vnd.api+json with
 any media type parameters."
  * "Servers MUST respond with a 406 Not Acceptable status code if a
 request’s Accept header contains the JSON API media type and all instances
 of that media type are modified with media type parameters."
  * "A document MUST contain at least one of the following top-level
 members:
       - `data`: the document’s “primary data”
       - `errors`: an array of error objects
       - `meta`: a meta object that contains non-standard meta-
 information."
  * "The members `data` and `errors` MUST NOT coexist in the same
 document."
  * "Primary data MUST be […] a single resource object […]
  * "A resource object MUST contain at least the following top-level
 members:
       - `id`
       - `type`
    Exception: The `id` member is not required when the resource object
 originates at the client and represents a new resource to be created on
 the server."
  * "In addition, a resource object MAY contain any of these top-level
 members:
       - `attributes`: an attributes object representing some of the
 resource’s data."
  * "The value of the attributes key MUST be an object (an “attributes
 object”). Members of the attributes object (“attributes”) represent
 information about the resource object in which it’s defined. Attributes
 may contain any valid JSON value."
  * "A JSON API document MAY include information about its implementation
 under a top level `jsonapi` member. If present, the value of the jsonapi
 member MUST be an object (a “jsonapi object”). The jsonapi object MAY
 contain a version member whose value is a string indicating the highest
 JSON API version supported."
  * "A server MUST return 403 Forbidden in response to an unsupported
 request to create a resource with a client-generated ID." (for the POST
 part)
  * "Error objects provide additional information about problems
 encountered while performing an operation. Error objects MUST be returned
 as an array keyed by errors in the top level of a JSON API document.
    An error object MAY have the following members:
       - `id`: a unique identifier for this particular occurrence of the
 problem.
       - `links`: a links object containing the following members:
            - `about`: a link that leads to further details about this
 particular occurrence of the problem.
       - `status`: the HTTP status code applicable to this problem,
 expressed as a string value.
       - `code`: an application-specific error code, expressed as a string
 value.
       - `title`: a short, human-readable summary of the problem that
 SHOULD NOT change from occurrence to occurrence of the problem, except for
 purposes of localization.
       - `detail`: a human-readable explanation specific to this occurrence
 of the problem. Like title, this field’s value can be localized.
       - `source`: an object containing references to the source of the
 error, optionally including any of the following members:
             - `pointer`: a JSON Pointer [RFC6901] to the associated entity
 in the request document [e.g. "/data" for a primary data object, or
 "/data/attributes/title" for a specific attribute].
             - `parameter`: a string indicating which URI query parameter
 caused the error.
       - `meta`: a meta object containing non-standard meta-information
 about the error."

 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.

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