Static File Introspection and Debugging

[thegreatfatzby]

The Access-Control-Allow-Origin "issue" I ran into made me think a bit more about debugging of the delegation file, which in turn made me think more about the debugging of static files in general. I know we have the ability to console.log from bidding/scoring/reporting/worklet functions today, and can also set breakpoints in the debugger, but I'm not sure how to handle a few cases.

Delegation File

I'm not sure how to do the following:

• See whether Chrome has tried to download a delegation file (in general or just for the current page).
• Understand why a delegation file might have been rejected.
• Try to force a refresh of the delegation file (I do think I'm seeing it cached at times).

I did an experiment and put some results here, the gist of which is that for various "delegation file failure scenarios" there isn't an "Issue" that pops up in the dev tools (contrary to the Cross domain header case where it does), and I'm not sure where else to look.

Can the downloading/parsing/eval'ing of that file result in console logs, or "issues"? Could there be a site, delegation-checker.chrome.com that will do a check for you? The cases I tested were bad http response code, bad mime type, bad json, blank, and bad value...a developer can debug this but the "silent failure" will be challenging.

Other Files

I'm curious about the same things for the attestation file, bidding and scoring functions, etc. For the files with code, one thing I'm not clear on overall is whether we can dive in on a particular auction that occurred during a page load to see things like the invited IGs, bidding files used, etc.

[dmdabbs]

• See whether Chrome has tried to download a delegation file (in general or just for the current page).

Before they plumbed many of these browser-issued background requests to DevTools, Network, one had to resort to a NetLog dump, https://www.chromium.org/for-testers/providing-network-details/. Well-known delegation requests should be listed there and whether it was serviced from cache.

I'm curious about the same things for the attestation file,

There's an intent to bundle the attestations file with Chrome. See https://issues.chromium.org/issues/40942169.

[MattMenke2]

It looks to me like PA's .well-known network fetches are not currently hooked up to devtools. Bidder/seller scripts and signals files are. Unfortunately, the way things work in Chrome, how and where requests are made affects whether they're logged to devtools. We have added code to wire up all requests made from the worklet process, but we have not added hooks specific to .well-known file fetches.

.well-known fetches are, of course, available in about:net-export (which includes all requests made globally), though that's not a great solution.