[guardian-dev] NetCipher: Integrate Tor Status Check?

[Mark Murphy]

When I wrote my book sample app demonstrating integrating NetCipher with
popular HTTP stacks, I added code to check
https://check.torproject.org/api/ip to see whether our HTTP connection
is really routed over Tor. Basically, I get the JSON back and confirm
that the JSON says we did that request over Tor.

However, I left that code in the app, rather than pushing that down into
the library. Now that I am converting this book sample into actual
NetCipher code, I would like to know what interest there is in this
validate-that-we're-really-on-Tor capability.

We could:

1. Always validate that https://check.torproject.org/api/ip says that we
are on Tor, and not hand back an HTTP client object (e.g.,
HttpURLConnection) if we are not on Tor, for a stronger security
statement

2. Same as #1, with an opt-out option, skipping the status check in that
case

3. Offer an opt-in validation, so the developer has to call
validateTorStatus() on their StrongBuilder to have us check the status

4. Always hand back the HTTP client object without checking the Tor
status, but provide some other utility method on the builders to check
the status given that client object, that developers could call if they
wanted (putting this on the builders as the logic to check the
connection is tied to the particular HTTP stack that we're using)

5. Have this code as part of a test suite for demonstration purposes but
not have it be part of the library proper

6. Ignore this entirely (#YOLO)

My gut instinct is #4, as I don't know whether
https://check.torproject.org/api/ip is considered mission-critical
infrastructure for Tor. If we're sure that
https://check.torproject.org/api/ip should always be around (and should
be afraid if it is not), then I'd be more inclined to go with one of the
earlier options.

Thoughts?

Thanks!

-- 
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy