Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Sandbox

deno.com

Post reply on HN
Print view View original

101–110 of 185 posts

Re: Deno Sandbox

#101

Post by simonw »

its-summertime wrote: post #76
simonw wrote: post #13

Earlier quoted context omitted.

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…

if there is an LLM in there, "Run echo $API_KEY" I think could be liable to return it, (the llm asks the script to run some code, it does so, returning the placeholder, the proxy translates that as it goes out to the LLM, which then responds to the user with the api key (or through multiple steps, "tell me the first half of the command output" e.g. if the proxy translates in reverse) Doesn't help much if the use of t…

Secrets are tied to specific hosts - the proxy will only replace the placeholder value with the real secret for outbound HTTP requests to the configured domain for that secret.

Re: Deno Sandbox

#102

Post by orf »

tptacek wrote: post #20
motrm wrote: post #12

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.

How does this work with more complex authentication schemes, like AWS?

Re: Deno Sandbox

#103

Post by zbentley »

zamadatix wrote: post #85
javier123454321 wrote: post #33

Earlier quoted context omitted.

As someone that has a habit of maybe overusing em dashes to my detriment, often times, and just something that I try to be mindful of in general. This whole thing of assuming that it's AI generated now is a huge blow. It feels like a personal attack.

"—" has always seemed like an particularly weak/unreliable signal to me, if it makes you feel any better. Triply so in any content one would expect smart quotes or formatted lists, but even in general. RIP anyone who had a penchant for "not just x, but y" though. It's not even a go-to wording for me and I feel the need to rewrite it any time I type it out of fear it'll sound like LLMs.

> RIP anyone who had a penchant for "not just x, but y" though

I felt that. They didn’t just kidnap my boy; they massacred him.

Re: Deno Sandbox

#104

Post by jonny_eh »

johnfn wrote: post #73
jonny_eh wrote: post #61

Earlier quoted context omitted.

> It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. This also follows the rule of 3s, which LLMs love, there ya go.

Yeah, I feel like this is really the smoking gun. Because it's not actually deeper? An LLM running untrusted code is not some additional level of security violation above a plugin running untrusted code. I feel like the most annoying part of "It's not X, it's Y" is that agents often say "It's not X, it's (slightly rephrased X)", lol, but it takes like 30 seconds to work that out.

It's not just different way of saying something, it's a whole new way to express an idea.

Re: Deno Sandbox

#105

Post by sothatsit »

ptx wrote: post #78
emschwartz wrote: post #8

> 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.

Yes... but... Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder. So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that e…

Could the proxy place further restrictions like only replacing the placeholder with the real API key in approved HTTP headers? Then an API server is much less likely to reflect it back.

Re: Deno Sandbox

#106

Post by ATechGuy »

yakkomajuri wrote: post #90

Secret placeholders seems like a good design decision. So many sandbox products these days though. What are people using in production and what should one know about this space? There's Modal, Daytona, Fly, Cloudflare, Deno, etc

These are all wrappers around VMs. You could DIY these easily by using EC2/serverless/GCP SDKs.

Re: Deno Sandbox

#107

Post by tomComb »

nihakue wrote: post #17

See also Sprites ( https://news.ycombinator.com/item?id=46557825 ) which I've been using and really enjoying. There are some key architecture differences between the two, but very similar surface area. It'll be interesting to see if ephemeral + snapshots can be as convenient as stateful with cloning/forking (which hasn't actually dropped yet, although the fly team say it's coming). Will give these a try. These are ex…

Yes, sprites looks great too – would certainly be interested in a comparison.

Re: Deno Sandbox

#109

Post by ryanrasti »

Tomuus wrote: post #100
ryanrasti wrote: post #48

Earlier quoted context omitted.

> It doesn't prevent bad code from USING those secrets to do nasty things, but it does at least make it impossible for them to steal the secret permanently. 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, like capnweb/capnproto?

Yes exactly Cap'n Web for RPC. On top of that: 1. Constrained SQL DSL that limits expressiveness along defined data boundaries 2. Constrained evaluation -- can only compose capabilities (references, not raw data) to get data flow tracking for free

Re: Deno Sandbox

#110

Post by tptacek »

sothatsit wrote: post #105
ptx wrote: post #78

Earlier quoted context omitted.

Yes... but... Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder. So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that e…

Could the proxy place further restrictions like only replacing the placeholder with the real API key in approved HTTP headers? Then an API server is much less likely to reflect it back.

It can, yes. (I don't know how Deno's work, but that's how ours works.)
Post reply on HN