[flagged]
How we run Firecracker VMs inside EC2 and start browsers in less than 1s
61–70 of 251 posts
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#62Just use something like https://shellbox.dev instead of FireCracker inside ec2. Much simpler, boxes are up in a couple of seconds, and it is way cheaper.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#63> Plain headless Chromium is easy to detect by websites with anti-bot measures. Plain headless Chromium avoided getting blocked by websites only 2% of the time, according to our stealth benchmark. > Our browsers avoid blocks 81% of the time on our stealth benchmark, and 84.8% on Halluminate BrowserBench, the highest of any provider. Seems very unethical, no? Who uses service providers like this? The whole point of an…
(I haven't tried this out yet.) My use case would be to take a snapshot of each HN story. This is surprisingly hard, because most websites prevent bots from doing that. For example, Claude has a lot of trouble reading HN's front page. HN itself is fine, but the moment you ask it to pick out an article, it often chokes. The website has put up a verification captcha, or it's a paywall, etc. Paywalls can be bypassed by…
> one bot taking a snapshot isn't going to make a difference
until half of HN users start asking their agent to do the same, to summarize the top HN articles every day
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#64[flagged]
Your whole account is undisclosed marketing for this service. Fingerprinting in this manner is highly unlikely to be viable - there are too many middleboxes at the TCP layer to try and fingerprint on it.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#65[flagged]
This only works if it's a proxy instead of an IP-layer tunnel. I suppose you could go a step further and validate whether the total ping is realistic, but this could be trivially solved by putting C2 close to the res-proxy endpoint.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#66have you tried running android browsers ? we run RL workloads using android browsers. We are having to maintain a fork of https://github.com/budtmo/docker-android/ and android chrome on top. We would rather use browser-use if it had that support. P.S. we do maintain our fork of a browser for rubric computation...but that is not relevant for this. The infrastructure is what we are looking for.
Shameless plug, we have the infra for exactly that use-case. Reach out if you're interested. Email in profile.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#67Earlier quoted context omitted.
You have to be a bit more restrictive today yes, but if you weren't already overrun with bots and hacking attempts while hosting a public service many years ago, you probably weren't hosting a even medium-popular website in the first place. Same thing goes today. Slap a rate limit on it and be done with it.
Yes, externalize the expense of dealing with it to each operator.
Been like that since what, early 2000s?
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#68I'm a bit surprised that with all this, they still stuck with Chromium.
We have a much less sophisticated setup in our web-access MCP server[0] where browser instances are spawned as subprocesses and the biggest win in stability, CPU and memory usage we had was in switching from Chrome to Lightpanda[1].
Fitting to the statement at the end of the article, the faster browser to boot might be one that allocates less memory in general.
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#69> Plain headless Chromium is easy to detect by websites with anti-bot measures. Plain headless Chromium avoided getting blocked by websites only 2% of the time, according to our stealth benchmark. > Our browsers avoid blocks 81% of the time on our stealth benchmark, and 84.8% on Halluminate BrowserBench, the highest of any provider. Seems very unethical, no? Who uses service providers like this? The whole point of an…
Whether or not scrapping publically available websites is unethical is probably up for debate. In some cases at least, courts have found it to be legal, even when the site is throwing up technical barriers or issues cease and desists. What is likely unethical is the fact that they offer residential proxies. The residential providers of those proxies are frequently not aware they’ve been opted in to provide such a ser…
> courts have found it to be legal
≠ ethical
Re: How we run Firecracker VMs inside EC2 and start browsers in less than 1s
#70> Plain headless Chromium is easy to detect by websites with anti-bot measures. Plain headless Chromium avoided getting blocked by websites only 2% of the time, according to our stealth benchmark. > Our browsers avoid blocks 81% of the time on our stealth benchmark, and 84.8% on Halluminate BrowserBench, the highest of any provider. Seems very unethical, no? Who uses service providers like this? The whole point of an…
Obviously don't know what percentage represents "legit" use cases vs other more morally questionable, but in our case we have a cms where content team can include external links and we need to verify periodically whether those links work or not, which is not as easy as making get requests with a client.