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 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
