@ai-ecoverse/slicc 1.49.9 → 1.49.11

package/README.md

@@ -801,7 +801,7 @@ Only browsers the user named are listed: the one seven runs in, `--cdp` and `--c
 - **Refused**, with `{"id":…,"sessionId"?:…,"error":{"code":-32000,"message":"slicc: refused: target is on seven's origin"}}`, never forwarded: `Target.createTarget`, `Page.navigate` and anything else whose `url` is protected (one that doesn't parse is refused with `slicc: refused: slicc can't parse this URL, so it could be a protected page`, see above); `Page.navigateToHistoryEntry` to an entry whose URL is protected (the node looks it up with `Page.getNavigationHistory`); `Target.attachToTarget`, `activateTarget`, `closeTarget`, `autoAttachRelated`, `Browser.getWindowForTarget` and any other command whose `targetId` or `frameId` is a protected target; and every command on a session whose target is protected, or became so. `Target.getTargetInfo` and `Target.detachFromTarget` stay allowed, except `Target.getTargetInfo` on a hidden target (see *Listing*).
 - **Origins and storage.** A command whose `origin`, `securityOrigin`, `ownerOrigin`, `issuerOrigin`, `topLevelOrigin`, `topLevelSite`, `embeddedOrigin`, `requestingOrigin`, `scopeURL` or `manifestId` is protected, or whose `storageKey` or `cacheId` names seven's storage, is refused the same way. This covers `Storage.*`, `IndexedDB.*`, `CacheStorage.*`, `DOMStorage.*`, `FileSystem.*`, `ServiceWorker.*`, `PWA.*`, `Browser.setPermission` and `Browser.grantPermissions`. Free-form values (`expression`, `arguments`, `value`, `headers`, `postData` and the like) aren't searched.
 - **Cookies.** `Network.getCookies`, `Network.getAllCookies`, `Storage.getCookies` and `Page.getCookies` answer without the cookies whose domain is protected (`sliccy.ai` and every subdomain, and each extra origin's host and its parents: cookies ignore ports), and without partitioned cookies whose `partitionKey.topLevelSite` is such a site. `Network.setCookie`, `setCookies`, `deleteCookies`, `Storage.setCookies` and `Page.deleteCookie` for such a domain, a URL on such a host, or a partition key under such a site, are refused with `slicc: refused: cookies on seven's origin`. So are `Network.clearBrowserCookies` and `Storage.clearCookies`, except in a browser context this stream created with `Target.createBrowserContext`.
-- **Requests a page makes to seven.** For a request whose URL is protected, `Network.*` and `Fetch.*` events lose their `Cookie`, `Set-Cookie`, `Authorization` and `Proxy-Authorization` headers (in the header maps and as lines of the raw header texts, which otherwise stay, their URLs cut as everywhere) and their cookie lists, and `requestWillBeSentExtraInfo` drops seven's cookies from `associatedCookies` for any request. Chrome can send `requestWillBeSentExtraInfo` and `responseReceivedExtraInfo` before the event that names the request's URL, so the node holds them until the request is found to be protected, gets its response, finishes or fails (a WebSocket or WebTransport once it is created); one still held after 2 seconds is passed on stripped, as for a protected request. For a WebSocket, WebTransport or EventSource on a protected origin (`ws:` and `wss:` count as `http:` and `https:`), `webSocketWillSendHandshakeRequest`, `webSocketHandshakeResponseReceived`, `webSocketFrameError`, `eventSourceMessageReceived` and `dataReceived` are dropped. Reading such a request's body (`Network.getResponseBody`, `Fetch.getResponseBody`, `takeResponseBody…AsStream`, `Audits.getEncodedResponse` and the like) is refused. A request paused at the response stage whose response headers name a protected URL (an ordinary redirect into seven, say) counts as such a request too. `Fetch.continueRequest` and `Network.continueInterceptedRequest` with a `url` that the node has seen redirect into a protected origin on that target are refused with `slicc: refused: that URL redirects to seven's origin`. So is reading a stylesheet or script that came from a protected URL, directly or through a redirect: `Page.getResourceContent` and `Page.searchInResource` for its URL, and any command naming its `styleSheetId` or `scriptId`. CSS rules and styles from it reach the page with only their `styleSheetId` and `origin`. In a dedicated, shared or service worker, the node keeps its own guard session (Network only), and the worker's commands, `Runtime.runIfWaitingForDebugger` included, wait until that session's `Network.enable` answers, within the same bounds as a page's guard. A worker script other than the worker's own is readable only if that guard saw its whole redirect chain and none of it was protected; an import from before the guard attached, such as in a worker that was already running, is refused. In a page, a stylesheet or script loaded before the node attached to the tab has no redirect chain the node saw, so it stays readable even if it came through a redirect from a protected origin (a known residual). The node also checks the answer, because the page may ask before the node has seen the request. When `Network.getResponseBody`, `searchInResponseBody`, `streamResourceContent`, `getResponseBodyForInterception`, `takeResponseBodyForInterceptionAsStream`, `getRequestPostData`, `Fetch.getResponseBody`, `Fetch.takeResponseBodyAsStream` or `Audits.getEncodedResponse` answers, the node holds the answer until the request has a response (for `getRequestPostData`, until it is sent; for an intercepted request, until it is paused). If the request is protected by then, the answer is refused, and a stream it handed out is closed. If the node still hasn't seen the request after 2 seconds, the answer is refused with `slicc: refused: slicc hasn't seen this request, so it could be seven's`. `Network.replayXHR` is refused with that message too, unless the node has already seen the request; for a protected request it is refused like the body getters. `IO.read` is refused, with `slicc: refused: slicc didn't hand out this stream, so it could be seven's`, unless the node passed that handle to the page in an allowed answer (`take…AsStream`, `Page.printToPDF`, or `IO.resolveBlob` as `blob:<uuid>`). - **Paused requests to seven.** A page session's own interception never gets to touch a request whose URL is protected, whatever its kind (a document, `fetch()`, XHR, an image or any other subresource), at either stage. The node keeps `Fetch.requestPaused`, `Fetch.authRequired` and the deprecated `Network.requestIntercepted` for such a request from the page and settles it itself:
+- **Requests a page makes to seven.** For a request whose URL is protected, `Network.*` and `Fetch.*` events lose their `Cookie`, `Set-Cookie`, `Authorization` and `Proxy-Authorization` headers (in the header maps and as lines of the raw header texts, which otherwise stay, their URLs cut as everywhere) and their cookie lists, and `requestWillBeSentExtraInfo` drops seven's cookies from `associatedCookies` for any request. Chrome can send `requestWillBeSentExtraInfo` and `responseReceivedExtraInfo` before the event that names the request's URL, so the node holds them until the request is found to be protected, gets its response, finishes or fails (a WebSocket or WebTransport once it is created); one still held after 2 seconds is passed on stripped, as for a protected request. For a WebSocket, WebTransport or EventSource on a protected origin (`ws:` and `wss:` count as `http:` and `https:`), `webSocketWillSendHandshakeRequest`, `webSocketHandshakeResponseReceived`, `webSocketFrameError`, `eventSourceMessageReceived` and `dataReceived` are dropped. Reading such a request's body (`Network.getResponseBody`, `Fetch.getResponseBody`, `takeResponseBody…AsStream`, `Audits.getEncodedResponse` and the like) is refused. A request paused at the response stage whose response headers name a protected URL (an ordinary redirect into seven, say) counts as such a request too. `Fetch.continueRequest` and `Network.continueInterceptedRequest` with a `url` that the node has seen redirect into a protected origin on that target are refused with `slicc: refused: that URL redirects to seven's origin`. So is reading a stylesheet or script that came from a protected URL, directly or through a redirect: `Page.getResourceContent` and `Page.searchInResource` for its URL, and any command naming its `styleSheetId` or `scriptId`. CSS rules and styles from it reach the page with only their `styleSheetId` and `origin`. In a dedicated, shared or service worker, the node keeps its own guard session (Network only), and the worker's commands, `Runtime.runIfWaitingForDebugger` included, wait until that session's `Network.enable` answers, within the same bounds as a page's guard. A worker script other than the worker's own is readable only if that guard saw its whole redirect chain and none of it was protected; an import from before the guard attached, such as in a worker that was already running, is refused. In a page, a stylesheet or script loaded before the node attached to the tab has no redirect chain the node saw, so it stays readable even if it came through a redirect from a protected origin (a known residual). The node also checks the answer, because the page may ask before the node has seen the request. When `Network.getResponseBody`, `searchInResponseBody`, `streamResourceContent`, `getResponseBodyForInterception`, `takeResponseBodyForInterceptionAsStream`, `getRequestPostData`, `Fetch.getResponseBody`, `Fetch.takeResponseBodyAsStream` or `Audits.getEncodedResponse` answers, the node holds the answer until the request has a response (for `getRequestPostData`, until it is sent; for an intercepted request, until it is paused). If the request is protected by then, the answer is refused, and a stream it handed out is closed. If the node still hasn't seen the request after 2 seconds, the answer is refused with `slicc: refused: slicc hasn't seen this request, so it could be seven's`. `Network.replayXHR` is never forwarded: for a protected or unknown request it keeps the body-getter refusal; for a known ordinary request it is refused with `slicc: refused: Network.replayXHR follows redirects inside the browser, so it could send a request to seven's pages or the vault`. Chrome's native replay cannot classify each redirect before sending it. This does not block page-initiated fetches, XHR or subresources, including their redirects into protected origins; C5 allows those requests while the content and credential protections still apply. A URL override through `Fetch.continueRequest`, a redirect supplied through `Fetch.fulfillRequest` or `Fetch.continueResponse`, and `Fetch.continueWithAuth` make the request client-issued. The guard correlates its network ID on that target and fails a protected hop before sending it; an unmodified page continuation does not establish client ownership. Missing correlation, an unguarded worker or exhausted ownership tracking refuses the client mutation. `Network.continueInterceptedRequest` with `url` or `rawResponse` is always refused, whatever the destination; use Fetch instead. Chrome 156 removed `Network.setRequestInterception`, so its compatibility refusal has committed wire coverage rather than a native control. `IO.read` is refused, with `slicc: refused: slicc didn't hand out this stream, so it could be seven's`, unless the node passed that handle to the page in an allowed answer (`take…AsStream`, `Page.printToPDF`, or `IO.resolveBlob` as `blob:<uuid>`). - **Paused requests to seven.** A page session's own interception never gets to touch a request whose URL is protected, whatever its kind (a document, `fetch()`, XHR, an image or any other subresource), at either stage. The node keeps `Fetch.requestPaused`, `Fetch.authRequired` and the deprecated `Network.requestIntercepted` for such a request from the page and settles it itself:
   - a document request is failed (`Fetch.failRequest` with `BlockedByClient`, or `Network.continueInterceptedRequest` with `errorReason: BlockedByClient`);
   - any other request continues untouched (`Fetch.continueRequest`, or `Network.continueInterceptedRequest` with only its `interceptionId`);
   - an auth challenge gets the browser's own handling (`Fetch.continueWithAuth`, or `Network.continueInterceptedRequest`, with `authChallengeResponse: {"response": "Default"}`).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc",
-  "version": "1.49.9",
+  "version": "1.49.11",
   "description": "SLICC's command line for seven: links a machine's network, compute and browsers to seven over WebRTC",
   "license": "Apache-2.0",
   "repository": {
@@ -18,12 +18,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@ai-ecoverse/slicc-darwin-arm64": "1.49.9",
-    "@ai-ecoverse/slicc-darwin-amd64": "1.49.9",
-    "@ai-ecoverse/slicc-linux-arm64": "1.49.9",
-    "@ai-ecoverse/slicc-linux-amd64": "1.49.9",
-    "@ai-ecoverse/slicc-windows-arm64": "1.49.9",
-    "@ai-ecoverse/slicc-windows-amd64": "1.49.9",
-    "@ai-ecoverse/slicc-jerk": "^1.2.3"
+    "@ai-ecoverse/slicc-darwin-arm64": "1.49.11",
+    "@ai-ecoverse/slicc-darwin-amd64": "1.49.11",
+    "@ai-ecoverse/slicc-linux-arm64": "1.49.11",
+    "@ai-ecoverse/slicc-linux-amd64": "1.49.11",
+    "@ai-ecoverse/slicc-windows-arm64": "1.49.11",
+    "@ai-ecoverse/slicc-windows-amd64": "1.49.11",
+    "@ai-ecoverse/slicc-jerk": "^1.3.0"
   }
 }