maniazi83

One thing we noticed while building OCR is that accuracy drops heavily with low-resolution scans and rotated documents. GPU acceleration helped speed, but preprocessing ended up being the bigger challenge. Curious how others handle that.

This is seriously impressive. Emulating x86 + stubbing enough Win32 APIs in the browser is not trivial.

How are you handling system calls that expect filesystem or registry access? Are those fully stubbed/mocked, or mapped to some in-browser virtual layer?

Also curious how you’re handling performance for heavier binaries — interpreted JS/WASM core?

One thing we intentionally avoided was long-term storage. Many file tools quietly retain inputs longer than users expect.

Our default model is:

Source deleted immediately after processing

Converted output expires after 24h

Logs retained up to 30 days (metadata only)

No file contents stored in logs

If anyone here runs file-processing infrastructure, I’d genuinely love to know — what retention window do you consider reasonable for this category?

Extra context: the goal was to be concrete (data lifecycle, retention, logs) rather than generic “we take security seriously” language. If there’s any security review question you’d expect answered on this page (sandboxing detail, threat model, key mgmt, etc.), tell me what’s missing and I’ll update it.