Nick Mathewson <[email protected]> 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 ;) -- meejah _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
