Microsoft and GitHub Sign-In Are Here, and Scans Are Now More Stable
This update has two halves: one you can see and one you mostly can't. The visible part is new ways to sign in. The rest is a set of stability and accuracy fixes, some of which came from a customer who took the time to send us detailed feedback.
Sign in with Microsoft or GitHub
Decloak sign-in used to mean Google, a passkey or an email magic link. Two more options are now live:
- Microsoft, covering both personal Microsoft accounts and Microsoft 365 work accounts.
- GitHub, for the developers who are already signed in there all day.
The full set is now Google, Microsoft, GitHub, passkeys and email magic link.
The reasoning is simple. Security teams and developers already live in Microsoft 365 or GitHub, and those accounts are usually protected with SSO and MFA. Signing in with an account you already protect is easier, and safer, than creating another password.
On privacy: Decloak never sees or keeps your password or the provider's token. The provider confirms who you are once, and then Decloak runs its own session. Every provider goes through the same callback flow, so team setup, redirecting you back to the page you came from and the MFA step all behave the same whichever button you click.
The browser crash that could take other scans down
This is the part we found most interesting, and it needs a bit of context.
The problem
Decloak drives a real browser with Playwright, an open-source automation library, to load pages the way a visitor would. There is a long-standing bug in Playwright itself: an internal "Assertion error" in its frame handling that fires during a race while a page is adding iframes. It has been open upstream for years, and the maintainers have never been able to reproduce it reliably.
The error is thrown from inside Playwright's own event handling, not from code we call, so no try/catch in our code can catch it. It surfaces as an unhandled error and takes down the whole process.
Why it mattered
Our background worker ran every job queue in one process: free scans, agent scans, pentests, webhooks and content jobs. So one bad page didn't only fail its own scan. It killed every other scan running at that moment, and those later showed up as confusing "stalled job" failures.
What set it off
Embedded video players, especially autoplaying ones. YouTube first, then Vimeo. They create and tear down iframes rapidly, which is exactly the race that trips the bug.
What we did
- Contain it. Global crash handlers now shut every queue down cleanly, alert us and let the worker restart. Before this we found out by reading raw logs.
- Reproduce it. We wrote a test harness that runs each attempt in its own child process, so a crash doesn't stop the test. With YouTube embeds blocked, we saw no crashes in all 32 test runs.
- Retry safely. Agent scans now retry automatically after a crash only if nothing had been saved yet. Otherwise they fail cleanly, so we never duplicate findings or waste AI spend.
- Block video players up front. YouTube, YouTube-nocookie, Vimeo and Wistia player iframes are now blocked on every scan, not just on retry. The request is logged before it is blocked, so the video host still appears in your third-party domain report. We only block embedded frames, so scanning youtube.com itself works as normal.
Reliability: retries, timeouts and headroom
- Database writes survive brief outages. Previously, one server error from our database provider in the middle of a crawl could fail an entire large scan. Writes now go in batches and retry on network failures, server errors and statement timeouts, waiting 1, 3, then 9 seconds. They are written so a retry can never create duplicate rows.
- Faster queries on large scans. Scans with more than 10,000 network requests were hitting a statement timeout while results were read back. New indexes make each page a quick lookup, and the "changes since last scan" section no longer loads the whole previous scan into memory.
- The live progress page reconnects. If the live feed drops because of a deploy, a network blip or a proxy closing an idle connection, the page now retries with increasing gaps for about two minutes, then re-fetches the saved state so nothing is missed. Before, it could show "connection lost" while your scan was running fine in the background.
- Pentest sandbox retries. Temporary sandbox errors such as timeouts, dropped connections, rate limits and server errors are retried up to twice. If a check still can't run, it is reported as "inconclusive", never as a clean pass. A failure in one tool category also no longer throws away results from the other five.
- More capacity. After repeated out-of-memory crashes, we gave the worker four times the memory.
Accuracy fixes that came from customer feedback
- WordPress version detection was wrong. The readme file stopped containing the WordPress version years ago, and our pattern was matching the text "GNU General Public License version 2" instead. Fully patched sites were reported as WordPress 2, with hundreds of CVEs and a score of 0. Detection now uses the RSS feed's generator tag and the version numbers on core WordPress files, and it refuses any "version" that isn't in a valid major.minor format.
- Scripts held back by caching plugins. Plugins such as LiteSpeed Cache, WP Rocket and Perfmatters can delay scripts until a visitor moves the mouse or scrolls. Seven of the nine sites did this, so their analytics and trackers never loaded in our scanner. When we detect those scripts, we now simulate a gentle mouse move and scroll (never a click), wait up to 5 seconds for them to load, and add a note to the report.
- A HubSpot false positive. The HubSpot tracking snippet was being read as "built on HubSpot CMS". Now only markers that HubSpot's CMS itself outputs count.
- Unreachable sites no longer get an A. If a firewall blocked us, no check could run, so nothing lost points and the site graded well. One site scored 75 (B) in the morning and 93 (A) in the afternoon once its firewall started blocking us. Now the scan ends as "We couldn't reach this site", with likely causes and the ports we tried, and no grade.
That last one matters most. A scanner that reports a clean score when it couldn't look is worse than one that says nothing.
Keep the feedback coming
Most of the accuracy work above exists because someone told us a result looked wrong. If a scan gives you something that doesn't add up, tell us. We would rather fix a false positive than have you learn to ignore the report.
Sign in with Google, Microsoft, GitHub, a passkey or a magic link, and run your first scan free. Try Decloak →