User Display and Control of Network Operations

[dnwiebe]

The original purpose of this card was to enable the user to malefactor-ban exit Nodes in real time, as they misbehaved in ways that require a human to detect; but once the infrastructure to enable that is in place, much more may be within easy reach.

Playing this spike will require close coordination with the front-end team.

The fundamental idea is that the Node will broadcast three more kinds of messages over MASQNode-UIv2 to the user interfaces, and will listen for at least one new kind of message from the UIs. Understanding the three new kinds of messages well enough to be able to send the one new kind of message will require a fair amount of effort on the part of the UIs.

New Node-to-UI broadcasts:

• Whenever the neighborhood changes, the Node will send a message containing a representation of the new version of the neighborhood, consisting of a list of Node entries each with the following fields:
  • public key
  • earning wallet
  • rate pack (that is, the amounts of money the Node charges per byte and per CORES package for routing and exiting)
  • accepts-connections flag (Originate-Only Nodes have this set to false)
  • routes-data flag (Consume-Only Nodes have this set to false)
  • the Node entry's IP address, if known
  • a list of hostnames that have been seen to be unreachable from this Node
  • probably other things here as the Node is enhanced in the future; ignored by the front end if not usable yet
  • list of public keys of Nodes which it counts as neighbors
• Whenever the Node forms a new route through the Network to an exit Node, or whenever one of those routes is discarded, the Node will broadcast its current list of routes to the UIs. Each route will have the following information:
  • stream key
  • list of public keys showing the route from the originating Node to the exit Node
  • list of public keys showing the route from the exit Node to the originating Node
• Whenever the browser (or other client) sends something over the MASQ Network, a record will be broadcast to the front end containing these values:
  • name of the server to which the request is being sent (not the URL: we can't see that)
  • stream key of the route being used
  • size of the request in bytes (to be determined: including how many layers of envelope?)
  • expected cost of the request

New UI-to-Node messages

• If the user decides that the desirability of a particular Node should be changed, the UI can send a message to the Node containing the public key of that Node, and one of the following adjustment values:
  • BAN: Impose a malefactor ban on the Node, meaning we will no longer traffic in Gossip or Data with the Node or pay it any money.
  • UNBAN: Remove the malefactor ban from a Node that was previously banned. This should be the only way a Node can possibly shed a malefactor ban, ever: it'll have to convince the user.
  • NEVER(X): Where X is exit, relay, or both: Continue Gossipping with the Node, and paying it whatever it's owed, but don't use it for the specified services anymore, unless the user says differently in the future.
  • LESS(X): Weight this Node so that it is used less often for the X service(s) than it has been. Sending several LESS messages in a row should reduce its use even further.
  • MORE(X): Weight this Node so that it is used more often for the X service(s) than it has been. Sending several MORE messages in a row should increase its use even further.
  • ALWAYS(X): Every route that is generated by the Routing Engine should use this Node for the specified service if it's at all possible. Exactly what is meant by specifying ALWAYS for the same service for several Nodes is not clear at the moment.

Further Notes:

• On some systems, the broadcasts might consume too many resources, or the users may simply be uninterested in them. There should probably be a way to turn them on and off at the user's discretion.
• BAN and UNBAN instructions involve the persistent database, and their effects will last beyond the shutdown of the Node. NEVER, LESS, MORE, and ALWAYS refer only to the current instance of the Node; if the Node is stopped and restarted, they'll be forgotten.
• Obviously, allowing the user to conveniently send desirability-change messages will involve processing the broadcast messages into some kind of display that the user can click on. We don't presume to dictate user experience, but we have some ideas.
• The UIs will have to display Nodes in a way that is visually compact, but nevertheless allows the user to tell Nodes apart at a glance and to recognize a particular Node when he sees it in different settings. However, the only Node descriptor we can reliably present will be the 32-byte binary public key. We suggest processing that 32-byte sequence into a distinctive colored icon that can be presented for the Node, in somewhat the same way GitHub generates avatars for users who have not yet set avatars.
• A representation of the user's neighborhood could be displayed as a partial mesh. The Node's patch of the network will include edge Nodes that mention the public keys of Nodes that do not appear in the broadcast; these are Nodes far enough away to be beyond the local patch, and could be represented as lines reaching off into the distance without termination.
• A link between two Nodes A and B can take four forms:
  • It may be missing entirely (no neighborship)
  • A lists B as its neighbor, but B does not list A as its neighbor (half neighborship)
  • B lists A as its neighbor, but A does not list B as its neighbor (half neighborship)
  • A and B each list the other as a neighbor (full neighborship); only in this state will traffic flow on the link.
• The proper method for displaying routes may not be instantly obvious. You might have a route over that looks like A -> B -> C -> D, and a route back that looks like D -> C -> B -> A. In that case, it'd be easy to represent it as A -- B -- C -- D on a single line. However, it's also possible to have a route over that looks like A -> B -> C -> D and a route back that looks like D -> E -> F -> A, or even D -> E -> B -> A. You could always display two route segments--over and back--and just duplicate Node avatars where necessary, but that might be visually confusing. Also, routes don't have to be four Nodes long, although they very frequently will be. They can be any number of Nodes long (except 0). We're sure glad we're not front-end developers.
• Transmission records could be displayed in real time in a scrolling list, with at least the host name and perhaps the exit-Node avatar showing in each row; if the user requested something with the browser and got a detectable spoof or a [CENSORED] page, he could find the transmission by host name in the scrolling display and click a button to BAN or NEVER that exit Node.

Issue for consideration during this spike:

• We already have the capability to store a list of unreachable hosts for each Node. Currently, we only put a host on that list if the corresponding Node can't find the host in its DNS. We should think about also accepting hosts for that list from the user. Maybe an exit Node is useful for most traffic, but certain hosts are DNS-poisoned for it; it would be nice to be able to use it to exit traffic it could handle, and only block traffic it couldn't.
• Another piece of functionality we've dreamed about for years is allowing users to pass around--or subscribe to--ban lists that allow one user's experience with an evil (or perhaps especially desirable) Node to be passed to other users in a manual, human-curated way. (That is, in a way that cannot be automatically abused by an attacker.) If the user had such a list, he could point the front end at it and have the front end parse it and convert it into a series of BAN/UNBAN/NEVER/LESS/MORE/ALWAYS commands. The front end could also theoretically produce such files, at least in part, by extracting the Node's experience with and preferences for the Nodes in its patch from the neighborhood broadcasts.
• The neighborhood broadcasts cannot serve as a replacement for the TRACE-level DOT graph dumps to the log. When we're doing forensic analysis on a logfile, it's important to know exactly what was in the neighborhood database at the very moment when a particular piece of Gossip was sent or received; so we need that information in the log as well as in the MASQNode-UIv2 broadcasts.

Task:
Coordinate with the front-end crew to turn this spike into a set of playable cards, possibly including other spikes.