[remixz]

(I'm an EM at Plus) It's a bit complex, and not quite perfect, but I'm pretty happy with what we've done so far. The first method is by looking at the HTTP status codes. Since we're running a full browser on our side, we can tell if the status codes that returned are different than the initial capture. We also have been training an image classification model on pictures of log-in screens — this has worked surprisingly well, honestly. We've started expanding it to other types of "incorrect" screenshot scenarios as well, like loading screens, and we're seeing some cool early results.

[wizofaus]

Ok but once it's recognised a login screen, what does it do? And presumably you can't use this for sites that require frequent MFA...

[babelfish]

From another commenter, it prompts the screenshot "owner" to refresh

[chairhairair]

Why would running a full browser be relevant to knowing HTTP statuses of requests?

[remixz]

Our product works by taking a screenshot using a headless Chrome instance. In this case, it's helpful because we can look at not just the status code of the HTTP request to the page itself, but also any resources the page may fetch. This is particularly useful for SPAs, since they may return a 200 for the page itself, but an API call they make might return a non-200 when logged out.