-
-
Notifications
You must be signed in to change notification settings - Fork 322
Description
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 giventab id
andurl
. -
close-tab
needs to close a Tab with a giventab id
. -
refresh-tab
needs to refresh a Tab with a giventab id
,url
andmode
. 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. -
navigate
needs to navigate a Tab to a new URL (and automatically set themode
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.