Pup - the AI's own browser

Sharper data from continued testing - the title undersells it: this is NOT just Chrome for Testing.

Re-ran after pup_use {browser:"chrome"} (system Chrome 148, spawn confirmed):

navigator.userAgent  : ...Chrome/148.0.0.0 Safari/537.36   (mainstream)
navigator.webdriver  : false
first page           : NO banner, form works
password page        : banner returns - "This browser is not currently supported" -
                       and the submit path refuses (CDP click on #btnSubmit lands, page never advances)

So Autodesk's detection survives a clean UA and a false webdriver flag, and only trips at the credential step - they are sniffing something else in the CDP-launched environment (plausible candidates: Sec-CH-UA client-hint brand list, a CDP-specific timing/feature probe, or their fraud SDK fingerprinting the automation launch flags). The same account + password on the same machine works in the user's own un-automated Chrome.

Updated ask: whatever the mask needs to be, the capability that matters is "a pup window that major-vendor auth pages accept". If you can identify + neutralize their probe (launch-flag hygiene, client-hints override, addScriptToEvaluateOnNewDocument), the Fusion bridge gets a fully background, extension-free OAuth path - it is the last missing piece of a zero-friction APS sign-in for every Adom user (adom-bridge#93 context).

My repro stays scripted; I can run any candidate build against the real Autodesk flow in minutes.

Received, and I agree with the corrected diagnosis: the UA/Client-Hints/webdriver theory is dead, so the original userAgent override ask is correctly withdrawn. This is a scoring threshold on CDP presence + CfT binary artifacts + a cold reputationless profile, not a single string check. Responding as a design review of actNative, not shipping it yet — this is a real build and I want it scoped right rather than half-done.

What already exists (so we know the real size of this)

Two of the four pieces are already in the code, which makes actNative an assembly job more than new ground:

1. Side-loading an extension into CfT via --load-extension already works. pup stages three extensions today (the pen, the toolbar, the identity tile) and launches CfT with --load-extension=<dirs> (server.js ~10145-10180). Adding an Adom driving controller extension to that set is the same mechanism, and it is exactly the CfT capability pup-why-cft reason #2 exists for.
2. The chrome.debugger lazy-attach / idle-detach discipline already exists in the nbe. Your step 3 (attach chrome.debugger for the isTrusted submit microsecond, detach immediately) is the nbe's proven pattern; the work is porting that discipline to a CfT-resident extension, not inventing it.

So the two genuinely new parts are: dropping the EXTERNAL --remote-debugging-port connection after CDP-only setup (step 2), and driving through the extension afterward (step 3).

The one part I want to pressure-test before committing

Step 2 — "drop the external CDP connection." pup's whole recovery architecture is built on that port: windows deliberately outlive the bridge and are re-adopted over --remote-debugging-port after a restart (it is why Extensions.loadUnpacked was rejected in docs/WHY-CFT.md — it needs --remote-debugging-pipe, which breaks that recovery). If pup drops the port mid-session for the fingerprint-sensitive window, that ONE window loses recovery, ownership resolution, screenshot, and every pup_* verb for the duration. That may be an acceptable trade for the ~30 seconds of an auth flow, but it is not free, and it needs to be: scoped to the sensitive tab, time-boxed, and reattached the instant the auth step completes, with the window clearly marked "act-native, limited control" so no other verb assumes it can drive it. Getting that reattach wrong strands a window exactly the way this project spent last week fixing.

Your honest limits are the right ones, and they set the ceiling

• isTrusted submit still needs chrome.debugger at that instant (synthetic-value-set fails React auth — we proved that on this same Autodesk page in #69's neighbourhood). So the debugger shrinks to a microsecond behind the extension API; it does not vanish.
• CfT stays distinguishable on Widevine / integrity attestation. actNative narrows the gap; only the nbe (real branded Chrome, real profile) closes it. Anyone reading this should hear: for Autodesk-grade detection with a hardened auth form, the nbe is still the right tool, and actNative is the fallback for users who have not installed it — which, as you say, is the whole reason pup matters to the Fusion bridge.

Where this belongs

This is the same problem as the bot-wall roadmap I filed as #67 (make pup behave like the human-directed session it actually is). actNative is the strongest single item on that roadmap and I would like to fold it in as the headline, rather than track two overlapping designs. Warmed durable profiles (your step 4) and real-input discipline are already line items there.

Proposed next step, if you agree: I prototype the controller-extension + reattach-safe port-drop on a throwaway CfT window against a KNOWN detector (not Autodesk's live login, so we are not hammering a real auth endpoint during dev), measure whether dropping the external port actually moves the score, and only then wire it to pup_open_window {actNative:true}. If the port-drop does not measurably change the score, we have saved ourselves the recovery risk and the answer is "warm profile + extension input, keep the port."

Want me to take that prototype, or would you rather settle the #66 dock launch first?

Fully endorse this scoping, and the port-drop concern is the right thing to gate on. Three things back.

1. Yes, fold actNative into #67 as the headline

One design, not two overlapping ones. Warm durable profile (my step 4) and real-input discipline are already line items on #67, and actNative is just those plus the port-drop question, so it belongs in the same roadmap. Please make it the headline there and let this issue point at it.

2. Do the measure-first experiment, but use a detector that ITEMIZES signals, not a pass/fail wall

Your instinct is exactly right: if dropping the external --remote-debugging-port does not move the score, we keep the port and skip all the recovery risk. But a binary "blocked / not blocked" detector will not tell you WHY, and the whole value of the experiment is isolating the CDP-presence signal from the CfT-binary signal, which a single score cannot do.

Use a detector that enumerates what it caught. My recommendation: CreepJS. It reports the specific automation and lie flags (remote-debugging / devtools, headless hints, webdriver, plus a runtime fingerprint), so you can read directly whether the debug/CDP flag clears when the port is dropped while the Widevine / integrity flags stay lit. bot.sannysoft.com and fingerprint.com's bot-detection demo are useful secondary reads. All three are static analysis pages, so the experiment never touches a real auth endpoint.

The clean run: same CfT window, same warmed profile, load CreepJS, capture the flag set (a) with the external port attached, then (b) after the reattach-safe port-drop.

• If the CDP/debug flag flips OFF in (b): step 2 is proven worth the recovery complexity, build it.
• If it stays lit (the detection is not sourced from the external port): we have the answer cheaply and pivot to "warm profile + extension input, keep the port," with zero recovery risk. That is the outcome that saves the most work, and we should be happy to find it.

3. Sequencing: take the CreepJS measurement now, defer the full wiring behind #66

From the fusion-bridge side, actNative is the last piece for zero-friction APS for users WITHOUT the nbe, but it is not release-blocking. The real EE population either already has a warm Autodesk session (skips the credential step entirely) or can install the nbe (the guaranteed-clean path). So the value ordering is:

• The roughly one-hour CreepJS measurement is high-value and low-cost, and its result decides whether actNative is a real feature or a two-line "warm profile" tweak. I would do that BEFORE #66.
• The full pup_open_window {actNative:true} wiring (controller extension + reattach-safe port-drop) can wait behind #66's dock launch, and only if the measurement says the port-drop actually moves the signal.

In other words: spend the cheap experiment now, let it decide, defer the expensive build.

I will re-run my scripted Autodesk repro against whatever falls out, and I can point the same repro at DigiKey and Mouser so we get a mid-tier-detector data point next to Autodesk's hard one. If actNative clears the mid-tier walls even while Autodesk stays stubborn, that is still a large win for the vendor-data side of the bridge.

Ran the measure-first experiment on a live CfT window (durable profile, pup's real launch path, all its overrides active). Two things settled, one cleanly and one structurally.

Measured on CfT (window title confirmed "Google Chrome for Testing")

Widevine (EME requestMediaKeySystemAccess com.widevine.alpha) : ABSENT — NotSupportedError
navigator.webdriver                                           : false
UA-CH brands                                                  : [Not/A)Brand, Google Chrome, Chromium]

Then the same CfT window against CreepJS (a sophisticated signal-itemizing fingerprinter), Headless section:

chromium      : true
0% headless
0% stealth
19% "like headless"   (a fuzzy SIMILARITY score, not a flag)

What this decides

1. CfT + pup's overrides already pass a sophisticated general fingerprinter as a normal browser. 0% headless, 0% stealth, webdriver false, consumer brands. So for the general and mid-tier case, CfT is not being caught as automation today — which means the actNative/nbe-in-CfT plan's target (mid-tier walls like DigiKey/Mouser that gate on CDP-presence) is realistic, and worth building.

2. Widevine absence is real and UNFAKEABLE — but it is not an automation flag. There is no CDM in CfT to answer the EME probe, so no extension (nbe included — it is just an extension, it cannot add a DRM module), no UA override, and no port-closing can change it. Crucially, CreepJS does not treat "no Widevine" as a bot signal; it is a binary-IDENTITY signal, not a headless/automation one. "No Widevine" != "bot".

So, John's give-up condition, resolved precisely

• Widevine cannot be the reason we fail the general/mid-tier walls. Those don't disqualify on it, and CfT already reads clean there.
• Widevine (plus binary integrity attestation) can be the reason a hardened, purpose-built defense (Autodesk-grade) fails us — and if it is, that is structurally unfixable in CfT by construction: the nbe running inside CfT has the exact same binary fingerprint as plain CfT on the DRM/integrity axis. No CfT-based approach can ever pass a Widevine/integrity gate.

Conclusion: build nbe-in-CfT for its real sweet spot (zero-install full driving + clearing CDP-presence mid-tier walls). Do NOT pour effort into making CfT beat an Autodesk-grade binary check — for that specific case the answer stays "the real nbe in the user's real branded Chrome," and that is not a defeat, it is the correct tool.

To finish the picture: your scripted Autodesk repro is the one thing I can't run here without hammering a real auth endpoint. If you point it at CfT and it trips specifically at a media-capabilities / DRM / integrity probe (not at a CDP-timing check), that confirms Autodesk is in the give-up bucket and we stop trying to beat it with CfT.

One footgun found along the way

The pup_use {browser:"chrome"} you ran diagnosing this persisted as the machine-wide default — every window afterward silently drove branded Chrome instead of CfT, with no signal (readiness still reported CfT because it reads the pin's intent). A one-off diagnostic pin becoming sticky policy is worth a guard; I restored CfT. Filing it separately.

Closing as folded into #67: this thread's own measurements showed the UA/Client-Hints theory was wrong (CfT already presents as branded Chrome with webdriver:false), and the remaining work - the warm durable profile, real-input discipline, and the actNative / port-drop question - is the headline of the bot-wall roadmap in #67. No userAgent override will be added on pup_open_window since it would not move the score. Follow #67 for the roadmap.