让知识彼此相连
知识图谱
沿着人物与判断，回到原始证据。
1 位人物 · 1 个来源 · 3 条观点
放回语境
Olivia Johnston
选择一条判断，追溯到它所在的原始对话。
现有隔离机制采用过时的信任单元
等分区块用于阅读定位，不表示排名或权重。
当前 1–3 / 共 3 条判断 · 按来源日期由新到旧
当前判断
现有隔离机制采用过时的信任单元
约翰斯顿指出，gVisor 和 Firecracker 等技术可将平台与用户彼此隔离、用户之间彼此隔离。她称这种信任单元已过时，并提出疑问：如何保护用户免受其‘自身’代码的侵害？
这些是个人表达的观点，并非共识度量。原始资料保持其原始语言。
支持这项说法
诸如 gVisor 和 Firecracker 之类的技术在近八年前就“解决”了“隔离”问题。但对我们而言不幸的是，它们所解决的是一种如今已过时的信任单元的问题。你该如何保护用户免受其“自己”代码的影响？
原始摘录
technologies like gVisor and Firecracker “solved” “isolation” nearly eight years ago. Unfortunately for us, they solved it for an now-outdated unit of trust. How do you protect users from their “own” code?
上下文
在 Modal，我们的客户依赖 Sandbox 来执行由其下游用户编写的、或者如今几乎完全由智能体编写的不受信任的代码。运行不受信任的代码并不是一个新问题：每家云提供商都必须从第 1 天起就这样做，以便将其平台与用户隔离开来，并将用户彼此隔离。幸运的是，
原始上下文
At Modal, our customers rely on Sandboxes to execute untrusted code written by their downstream users or, almost exclusively now, by agents. Running untrusted code isn’t a new problem: every cloud provider has to do this from day 1 to isolate their platform from their user and their users from each other. Fortunately,
日期表示来源发表时间，不代表观点发生变化。 缺少审核合格译文的内容保留原文。