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:
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.
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.sessionproperty, and only does this on theconnection.sessionwithout 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:historyInternal Page).For now, the necessary functionality is this:
open-tabneeds to open a Tab with a giventab idandurl.close-tabneeds to close a Tab with a giventab id.refresh-tabneeds to refresh a Tab with a giventab id,urlandmode. This leads to a new Request being done viastealth.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.navigateneeds to navigate a Tab to a new URL (and automatically set themodecorrectly).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.