* Description: Discussing and comparing notes on building Tor-based apps such as Rico and Cwtch
* Priority: low
\ No newline at end of file
* Priority: low
## PieroV's notes
### Lessons learned from Onion Scan:
- Several sites forgot to remove GPS coordinates and other metadata.
- Apache has a status page on localhost enabled by default, and Tor looks like localhost, so the status page was available and the service could be deanonymized easily
So, their solution was moving to an ad-hoc app: cwtch (which was initially only a PoC).
### Whishlist for Arti:
- easier control of what tor is doing
- Openprivacy reused an existing project, that got abandoned, and so they had to fork and start maintaining
- annoying problems with string conversion
- richard: control port protocol is a gigantic initial difficulty
- c-tor uses torrc, and one of the things that several apps do is writing directly to it
- arti already has the possibility to reconfigure at runtime?
- nickm: chicken&egg problem: you need to use c-tor now, because arti doesn't have onion services, but they'd like to have a list of what users need
- circuit display: users like seeing it, and it's always a feature request. Also Tor Browser could benefit from a better way of getting circuits
- nickm: please find more information that "users want it", because this might leak information. So, we should think more about it.
- my request: have at least an API to query the bridge that is in use, for the sharing thing (i.e., tell the user which brdige they are using and works in the conditions they are)
- if you use system Tor, authorizations on onion services are shared between all users of that daemon instance.
nickm's suggestion: start having a look at the docs already! The earlier the better, because so they can change it before 2.0.0.
See arti.torproject.org for all links
### How are PTs going to work with Arti?
- 1.1 (ETA October?) should have compatibility with c-tor for PTs.
- Might not support all features, because some are simply not used.
- they might experiment with in-process PTs, but someone should come with the API to use (iiuc, with a design for the API that might desirable)
- Richard's request: handle relative paths (better?), because thing might break when people move things, or for portable setup
- Ian's idea: create some FFI that resembles that current fork approach.
- Not very nice, in his opinion, and for this reason people won't use it.
### Online test
Dan's question: every now and then they try to self-connect to see if a service is online. The reconnect command seems not to work (especially when hopping from one network to another one).
- nickm: tor has some code that detects if the IP/network is changing. But you have to log at the logs.
- Roger: there's a c-tor bug, which is a cache problem, for which tor refuses to connect to a service because it cached that it wasn't available
- nickm: they can add tests to simulate network changes and other funky stuff, but they'd like a list of possible scenarios to add them to their tests
- (roger had other suggestions, like take control of tor etc etc)
### Other questions and suggestions
There is a limit on the number of circuits that can be opened within a minute to prevent abuses.
**You must keep your logs enabled to debug any bug you have**! That's the only way.
Dan's request: expert builds for all platforms
Another topic: nickm explained how to make the control port more private (I haven't really understood, if I understood correctly anonymous pipes/sockets were involved, but it isn't really a cross platform thing, especially not supported on Windows).