Closed bug report

isolated:true does not isolate: the window still runs on the adom-you profile

John Lauer · 1mo ago ·closed by John Lauer

isolated:true does not isolate. It shares the adom-you profile.

Observed on 2.0.553, Windows, Rust shell. pup_open_window with isolated:true plus an isolationReason returns a window whose pup_window_info reports profile = adom-you, i.e. the same durable jar every default window uses.

Cause looks like rust/verbs/src/lib.rs:1039, which is the only place profile is bound:

let profile = args.get("profile").and_then(|p| p.as_str()).unwrap_or("adom-you").to_string();

isolated is read at 1057 and used only to keep the window on the CDP lane (line 1058) and to select the anonymous identity tile. Nothing derives a throwaway profile name from it.

Why this matters more than a cosmetic bug:

  • isolated:true is REASON-GATED. Callers must state why the window must NOT be adom-you, which strongly implies the request is honored.
  • The pup skill tells callers to use it for logged-out views, acting as a different user, and untrusted pages, and states that an isolated window discards its logins so they build nothing. If the jar is actually adom-you, a login performed in a supposedly throwaway window persists into the shared profile, and an untrusted page runs against the users real cookies.
  • It also silently invalidates any experiment that uses isolated:true as a fresh-profile control. That happened here: a warm-versus-fresh comparison ran adom-you twice and the wrong conclusion was published before it was caught.

Expected: isolated:true mints a throwaway profile directory (or an explicit named profile) distinct from adom-you, and pup_window_info reports that profile.

Either fix the behaviour or, if sharing the jar is deliberate, change the verb contract and the skill text so nobody relies on isolation that does not exist. The current combination of a mandatory reason and no isolation is the dangerous case.

4 Replies

John Lauer · 1mo ago

Status 2026-09-14: since 2.0.563 a request with isolated:true (or profile, highFps, webSecurity:false) without lane:"cdp" is refused with cdp_lane_required, so nobody gets a window they believe is isolated when it is not. The isolation itself is still not implemented: isolated:true with lane:"cdp" still binds profile to adom-you unless profile:"" is passed. A separate profile per lane is backlog (#113). Leaving open for the real fix.

John Lauer · 1mo ago

Fixed in pup 2.0.648 (insiders): isolated:true with no explicit profile mints a throwaway profile named iso-, pup_window_info reports it, and the directory is removed once the window's browser has let go of it (measured on ConfRoomROG: profile iso-30ae0de628 minted, reported, and the log shows 'throwaway profile ... removed' 25 s after pup_close). It still requires lane:"cdp" (the 2.0.563 refusal stands): the extension lane is one browser on adom-you, and a lane per profile is #113, which stays open as the design item.

John Lauer · 1mo ago

Reopened by John's rule: closing this on the CDP lane was a crutch. isolated:true must work on the extension lane (a second lane browser on its own throwaway profile, the #113 design), and from 2.0.652 the CDP lane is off by default (cdp_lane_disabled unless pup_configure {cdpLane:"on"}) so an AI cannot reach for it. The iso- profile minting and cleanup from 2.0.648 stay; only the lane changes.

John Lauer · 1mo ago

Fixed for real in pup 2.0.659/2.0.660 (insiders): isolated:true mints an iso- profile AND opens it in its own extension-lane browser (see #113), so the window shares nothing with adom-you: measured on ConfRoomROG, https://httpbin.org/cookies in the isolated window read {} while the default lane stayed signed in, pup_window_info reports the iso- profile, and closing the window ended that browser and removed the profile. No lane argument, no CDP (the CDP lane is off by default since 2.0.652).

John Lauer closed this · 1mo ago

Log in to reply.