Stealth: Session Service

[cookiengineer]

The Session Service should reflect the state of Tabs, their history and interactions thereof, which means that there has to be a WebSocket API that influences the connection.session property, and only does this on the connection.session without influencing any other data structures.

Sessions are already per-host and per-remote, and automatically merged once a peer is recognized with their domain name identifiers instead of only via their IPv4 or IPv6 IPs. As the Peer Discovery automatically leads to peer/host settings updates once peers have discovered themselves, this is transparently done by the Peerer.

The Session service, however, is there to persist Tabs and their history; so that a Browser session can be recovered for each Peer; and synchronized accordingly (for the later stealth:history Internal Page).

For now, the necessary functionality is this:

• [ ] open-tab needs to open a Tab with a given tab id and url.
• [ ] close-tab needs to close a Tab with a given tab id.
• [ ] refresh-tab needs to refresh a Tab with a given tab id, url and mode. This leads to a new Request being done via stealth.request(url) that automatically updates the cache; and fires a response event once the request was successfully done or led to an error or redirect.
• [ ] navigate needs to navigate a Tab to a new URL (and automatically set the mode correctly).

The tab.requests[] property might be totally unnecessary. The previous idea was to match everything correctly for Webproxy-using third-party Browsers (using Stealth as a Web Proxy). But this is deprecated due to its unnecessary complexity; and attack surface in the sense that an attacker could potentially craft a couple of HTTP requests (combined with ARP spoofs) that lead to changes in the UI on different Peers.