Nick Mathewson nickm@torproject.org writes:
But I could be wrong! Maybe there are subsets that are safer than others.
So, I guess the "main" use-case for this stuff would be the current users of control-port filters (like Subgraph and Whonix; others?).
It seems what these things *really* want is a "limited view" of the One True Tor. So for example, you don't want to filter on the "command" or "event" level, but a complete coherent "version" of the Tor state.
As in: see "your" STREAM events, or "your" HS_DESC events etc. Probably the same for BW or similar events. This is really kind of the "capability system" you don't want, though ;)
Also, I really don't know exactly what the threat-model is, but it does seem like a good idea to limit what information a random application has access to. Ideally, it would know precisely the things it *needs* to know to do its job (or at least has been given explicit permission by a user to know). That is a user might click "yes, OnionShare may add onion services to my Tor" but in reality you have to enable: ADD_ONION, (some) HS_DESC events, DEL_ONION (but only ones you added), etc. If you really wanted an "on-disk" one (i.e. via HiddenServiceDir not ADD_ONION), then you have to allow (at least some) access to SETCONF etc.
Or, maybe you're happy to let that cool visualizer-thing have access to "read only" events like STREAM, CIRC, BW, etc if you know it's sandboxed to have zero network access.
As above, appears to allow HS_DESC events. It allows "GETINFO onions/current", which can expose a list of every onion service locally hosted, even those not launched through onionshare.
Doesn't this just show "onions that the current control connection has added"?
- Some applications that care about their own onion services
inadvertantly find themselves informed about everyone else's onion services. I wonder if there's a way around that?
HS_DESC events include the onion (in args) so could in principle be filtered by a control-filter to only include events for certain onions (i.e. those added by "this" control connection). In practice, this is probably exactly what the application wants anyway.
E. Your thoughts here....?
Maybe this is a chance to play with a completely different, but ideally much better "control protocol for Tor"? The general idea would be that you have some "trusted" software (i.e. like existing control-port filters) that on the one side connects to the existing control-port of Tor (and is thus "completely trusted") but then exposes "the Next Great Control Protocol" to clients.
Nevertheless, there's still the question of what information to expose (and how) -- i.e. the threat model, and use-cases.
Of course, the same idea as above could be used except it speaks "Tor Control Protocol" out both sides -- that is, 'just' a slightly fancier filter.
signing-off-before-this-turns-into-a-capabilities-based-system,
Aww, that's what I want ;)