chore: remove unnecessary console logging in bootstrap.js

[anupamme]

Summary

Small diagnostic-hygiene cleanup in bootstrap.js: removes three console.log() calls from the extension's background script and tightens the code comment left behind. This is not a fix for a demonstrated exploitable vulnerability — see discussion below.

What was removed

• onCreated(windowInfo): logged the created window's ID (window-lifecycle info only).
• onCloseExtensionWindow(windowId): logged the closed window's ID (window-lifecycle info only).
• onError(error): logged the rejection value from the browser.windows.create(...) promise — a generic WebExtensions API error, not extension data.

Why

I looked at the actual data flow in bootstrap.js and want to correct my original PR description, which overstated this as a HIGH-severity vulnerability. That framing doesn't hold up:

• bootstrap.js never touches SAML request/response/assertion data, captured HTTP traffic, or traced URLs. That data lives entirely in src/SAMLTrace.js / src/SAMLTraceIO.js, which this file doesn't import or call into.
• Two of the three logs printed only a window ID. The third (onError) can only receive whatever browser.windows.create() rejects with — a standard browser API error (e.g. an unsupported window type/geometry error), not tracer data.
• I don't have evidence that a SAML assertion currently reaches any of these log statements.

Given that, I'm reframing this as a small defensive/privacy cleanup rather than a vulnerability fix: it reduces unnecessary background-page console output and guards against accidentally logging something sensitive if this code changes in the future — not against a demonstrated leak today.

Changes

• bootstrap.js — remove the three console.log() calls; comment in onError now accurately describes why it's left silent.

Happy to close this if you don't see value in the log removal itself.

[tvdijen]

Why would it be an issue if a SAML assertion is logged to the console? I don't see what you're trying to fix here

[anupamme]

Thanks for pushing back on this — you're right to question it.

I went back and traced the actual data flow in bootstrap.js. It never touches SAML assertions, requests, or captured traffic — that all lives in src/SAMLTrace.js / src/SAMLTraceIO.js, which this file doesn't import. Two of the three removed logs (onCreated, onCloseExtensionWindow) only ever printed a window ID. The third (onError) is the rejection handler for browser.windows.create(...), so it can only receive a generic WebExtensions API error, not tracer data.

So: I don't have evidence a SAML assertion currently reaches any of these logs, and my original HIGH-severity/vulnerability framing was wrong. I've updated the PR description and title to reflect that — this is now just a small diagnostic-hygiene cleanup (less unnecessary console output, some guard against a future accidental leak if this code changes), not a fix for a demonstrated issue.

If you'd rather not take the cleanup as-is, I'm fine closing this.

[tvdijen]

I'm just questioning it.. What would be the problem if an assertion did end up in the console log?
It still doesn't leave the context of the browser. To me it's not different from showing the assertion in the extension-window, unless I'm missing something obvious here.

[kellenmurphy]

I'd leave the console logging in place.

[anupamme]

That makes sense. I was treating console output as a separate disclosure surface without establishing a meaningful security boundary between the extension UI and its console. Given that both remain within the browser/extension context, I agree that logging an assertion there isn’t materially different from displaying it in the extension window.

And since the existing logs are useful diagnostics, I’ll leave them in place and close the PR. Thanks for the clarification.