Screen Feedback When IT Blocks Browser Extensions

You opened a ticket two weeks ago to get a feedback browser extension whitelisted, and it is still sitting in the security review queue. Meanwhile the staging site needs eyes on it before Friday, and the freelance designer you hired cannot install anything on her managed laptop either. The tool everyone recommended is technically free, but the install requirement has quietly turned it into a multi-week procurement problem.

This is the recurring failure mode of extension-based feedback tools like BugHerd, Marker, and Markup.io. They do good work once installed. Getting them installed is the bottleneck nobody mentions in the demo.

Why IT will not just approve the extension

A browser extension runs with broad permissions. Most feedback extensions request access to read and change data on all websites you visit, because they need to overlay a comment widget on whatever staging URL you point them at. From a security team's perspective that is the same permission set a credential stealer asks for. The extension is fine. The permission scope is what stalls the review.

So the security team does the responsible thing: they read the manifest, check the vendor, look at data residency, ask whether comments leave the network, and put it in a queue behind the other forty requests. In regulated industries (finance, health, government contractors) this can run six to twelve weeks. In agencies, the problem flips: your team is fine, but every new client has a different IT policy, and the freelancer on the project has a locked-down laptop from her last full-time job.

There is a second pattern that kills these tools even after approval. The extension has to be installed by every person whose feedback you want, including the marketing director who reviews the site twice a year and the external stakeholder who only needs to comment on the homepage. Asking those people to install something to leave a single comment is how feedback rounds die.

What a browser-only capture actually does

The browser already has the APIs you need. getDisplayMedia lets a web page ask permission to read a window or screen, draw the current frame to a canvas, and hand you back an image. The Web Speech API in Chrome and Edge transcribes dictation locally. Between those two, a plain tab can do most of what an installed annotation tool does, with one tradeoff: you crop a captured still rather than drawing arrows on the live page.

Cobalt Capture is built on exactly that. You open a tab, click Capture screen, pick the window you want, and the frame becomes an item in your review. You crop if you need to, drop a numbered pin where the bug is, and dictate or type the comment. No install, no extension, no signup. If you want to keep your reviews permanently you can sign in with Google or a magic link, but you do not have to: anonymous reviews stick around for 30 days and can be claimed later. It works as a drop-in alternative to BugHerd for the specific job of getting feedback out the door without an install.

How to run a review when nobody can install anything

The pattern that works in locked-down environments looks like this. Send reviewers a URL to start a new review in their browser. They capture the screens that matter, talk through each one, and click Publish. They get back a short public link of the form /r/<slug> that anyone can read without an account. The same review is available as a PDF, a Word document, and as plain markdown at /r/<slug>/markdown.

That output range matters because the people receiving feedback are not all the same. A client services lead wants the PDF for the project folder. A developer wants the public link so they can click each screenshot and read the threaded comments. If the work goes to an AI coding agent, the markdown export drops straight in: see the notes on how markdown screenshots work and the broader format agents read cleanly.

For ongoing review work, the common scenarios fit the same pattern. Staging site reviews where external testers cannot install anything. Client feedback rounds where the client's marketing team is not going to whitelist a vendor. QA bug reports from contractors on managed devices.

The tradeoffs to know before you switch

Browser-only capture is not identical to an installed extension. Three differences are worth being honest about.

First, you crop a captured still rather than drawing on the live page. If your team's workflow depends on highlighting a specific div on the rendered DOM with a colored box, that is not what this does. You get a screenshot, a crop, and numbered pins pointing at locations. In practice that is enough for almost every bug and design comment, and it sidesteps the entire class of problems where annotations break when the page changes.

Second, dictation depends on the browser. Chrome and Edge have it built in. Firefox does not, so Firefox reviewers type their comments. That is a per-reviewer choice, not a blocker.

Third, this is not a bug tracker. There is no kanban board, no assignees, no workflow states. Each item in a review can collect comments from anyone with the link, and the owner marks comments resolved. If you need ticket workflow on top, the review link goes into Jira or Linear like any other artifact.

If the extension request has been sitting in your security queue for more than a week, stop waiting. Open a tab, capture a screen, and send the link. The receiver does not need to install anything either.