4 ms·
(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 stat
by remixz 4y ago
(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.
- deleted 4y ago[deleted]
- chairhairair 4y agoWhy would running a full browser be relevant to knowing HTTP statuses of requests?
- remixz 4y agoOur 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.
- wizofaus 4y agoOk 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 4y agoFrom another commenter, it prompts the screenshot "owner" to refresh