41–50 of 185 posts
Earlier quoted context omitted.
Has everyone really built their own microVMs? I don’t think so.
Saw quite bit on HN. A quick search this popped up: https://news.ycombinator.com/item?id=45486006 If we can spin up microVM so quickly, why bother with Docker or other containers at all?
The real question is can the microVMs run in just plain old linux, self-hosted.
> In Deno Sandbox, secrets never enter the environment. Code sees only a placeholder > The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless. That seems clever.
Where's the real value for devs in something like this? Hasn't everyone already built this for themselves in the past 2 years? I'm not trying to sound cheeky or poo poo the product, just surprised if this is a thing. I can never read what's useful by gut anymore, I guess.
Sandboxes with the right persistence and http routing make excellent dev servers. I have about a million dev servers I just use from whatever computer / phone I happen to be using. It's really useful to just turn a computer on, use a disk, and then plop its url in the browser. I currently do one computer per project. I don't even put them in git anymore. I have an MDM server running to manage my kids' phones, a "help…
Earlier quoted context omitted.
Saw quite bit on HN. A quick search this popped up: https://news.ycombinator.com/item?id=45486006 If we can spin up microVM so quickly, why bother with Docker or other containers at all?
I think a 413 commit repo took a bit of time.
What happens if we use Claude Pro or Max plans on them ? It’ll always be a different IP connecting and we might get banned from Anthropic as they think we’re different users Why limit the lifetime on 30 mins ?
For what it's worth, I do this from about 50 different IPs and have had no issues. I think their heuristics are more about confirming "a human is driving this" and rejecting "this is something abusing tokens for API access".
>Deno Sandbox gives you lightweight Linux microVMs (running in the Deno Deploy cloud) The real question is can the microVMs run in just plain old linux, self-hosted.
Unfortunately there's no other way to make money. If you're 100% liberally licensed, you just get copied. AWS/GCP clone your product, offer the same offering, and they take all the money.
It sucks that there isn't a middle ground. I don't want to have to build castles in another person's sandbox. I'd trust it if they gave me the keys to do the same. I know I don't have time to do that, but I want the peace of mind.
> In Deno Sandbox, secrets never enter the environment. Code sees only a placeholder > The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless. That seems clever.
Yeah, this is a really neat idea: https://deno.com/blog/introducing-deno-sandbox#secrets-that-... await using sandbox = await Sandbox.create({ secrets: { OPENAI_API_KEY: { hosts: ["api.openai.com"], value: process.env.OPENAI_API_KEY, }, }, }); await sandbox.sh`echo $OPENAI_API_KEY`; // DENO_SECRET_PLACEHOLDER_b14043a2f578cba75ebe04791e8e2c7d4002fd0c1f825e19... It doesn't prevent bad code from USING those secrets to d…
Agreed, and this points to two deeper issues: 1. Fine-grained data access (e.g., sandboxed code can only issue SQL queries scoped to particular tenants) 2. Policy enforced on data (e.g., sandboxed code shouldn't be able to send PII even to APIs it has access to)
Object-capabilities can help directly with both #1 and #2.
I've been working on this problem -- happy to discuss if anyone is interested in the approach.
Earlier quoted context omitted.
Reminds me a little of Fly's Tokenizer - https://github.com/superfly/tokenizer It's a little HTTP proxy that your application can route requests through, and the proxy is what handles adding the API keys or whatnot to the request to the service, rather than your application, something like this for example: Application -> tokenizer -> Stripe The secrets for the third party service should in theory then be safe should…
It's exactly the tokenizer, but we shoplifted the idea too; it belongs to the world! (The credential thing I'm actually proud of is non-exfiltratable machine-bound Macaroons). Remember that the security promises of this scheme depend on tight control over not only what hosts you'll send requests to, but what parts of the requests themselves.