111–120 of 251 posts
Earlier quoted context omitted.
Your solution sounds very expensive.
From our production stats, a median screenshots capture is 5.7s. Browser-use bills per minute, not per millisecond like lambda does. As is, it's around 2x more expensive than Lambda for our use-case.
Earlier quoted context omitted.
I never suggested reuse.
Starting the VM itself takes 20ms with Firecracker, the slowest part is starting the browser. So there's no benefit on reusing the VM but not the browser. VM isolation is also important, customers can leave downloads and other files that should not be accessible for freshly created browsers on that same VM.
What is firecracker needed? Couldn’t this just run in a container directly? I understand some of the isolation concerns but a browser and container breakout is a billion dollar CVE, no?
[flagged]
You seem to be affiliated to that clearly slopped service. Your rate of comments seems to be low enough to make it plausible that you're not just shilling, but could you at least disclose your relationship to that product whenever you mention it?
Earlier quoted context omitted.
docker is not a security boundary but a resource boundary.
It is security boundary but a weak one. Escaping from docker is very hard.
You mean a microVM.
A docker LPE (local privilege escalation) requires a kernel exploit such as Copyfail would work under docker but not in a microVM.
> Next: skip Chromium startup > This is complex, as a running browser has open devices, timers, graphics state, network state, and fingerprint state. Hmm, can't you just keep a set of browsers already running, like a warm pool, ready to assign to an incoming request? The latency would be close to zero for the user. You'd need some prediction logic to expand / contract the warm pool based on traffic patterns, but that…
Yes, warm pool work, but our goal is to replace them at all. Warm pools are nice but at the end they also consume resources, And you need to always keep the pool warm, starting browsers to balance, etc... With the upcoming changes we will keep Chromium startup and the VM will be ready in 50ms, defeating warm pools at all Also some customers need special parameters and features, increasing warm pools complexity. The h…
Earlier quoted context omitted.
If you follow the kernel mailing list container breakout exploits are currently a weekly occurrence
Oh really, not a security expert, but could you send me some examples?
Earlier quoted context omitted.
Starting the VM itself takes 20ms with Firecracker, the slowest part is starting the browser. So there's no benefit on reusing the VM but not the browser. VM isolation is also important, customers can leave downloads and other files that should not be accessible for freshly created browsers on that same VM.
I never suggested reuse.
Keeping the browser open and warm is also a problem, not all customers require the same features. The same engineering required to fix that (modifying values with Chromium open), also fixes the post-chromium snapshot
VM takes 20ms to start, browser around 300ms. Post-Chromium snapshot is at 50ms end-to-end, defeating the benefits of the warm pool you suggest, that will be our next step.
>During a burst in traffic, the system, instead of reacting on its own, required humans to adjust it. This caused problems: one load test brought down production for 45 minutes. So we rebuilt our setup on Firecracker.
It shouldn't need to have autoscaling built in. If the variable is adjustable, why couldn't monitoring happen that sets off a process to adjust the variable when traffic spikes?