You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 theconnection.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.The text was updated successfully, but these errors were encountered: