Docker does not and cannot offer full isolation. A sandboxed VM on someone else's computer is less likely to be problematic for running untrusted code than a container on your system.
seems not to justify submitting to a proprietary single vendor solution where users are locked into opaque checkpoints they forgot how to migrate away from. this is not something made for users lets be clear. there are tens or hundreds of vm layers for defense in depth for docker so thats a non argument, no one says docker has to provide security its for tooling and common practices that allow vendor independence and moving to self hosted stacks as needed!
i hope this is a fringe opinion as im usually putting icons on every item and found it leads to reduced mental overload and fast item selections, for complex menus i would even go so far as making it colored to more senses can be used. the icons have to be meaningful though, apples guidelines specifically mention arbitrary icons not icons at all
I hope so too, and I agree on the colored icons for pro apps. Mac user for 20 years, also using Windows on and off, and I've always liked the menu icons on Windows. A move away from minimalism that makes sense. The fact that they're not cargo-culting their 20 year old HIG is promising, really.
But they really should keep the indentations consistent, they're increasing cognitive load for no reason by not doing that.
I also like the hotkeys or whatever (the underlined letter in menu items and dialog box buttons), and maybe that is a fringe opinion among Apple users.
I want icons everywhere. They can literally be meaningless but it’s way way easier to find “2nd item in matching icon set” than it is to read every item in a list.
By what definition is this local first? You use firebase and the client is not open source or at least downloadable. The definition is that i can keep using the app if your company goes out of business, which is not the case.
It's local-first in the sense that all your financial data is local (synched across your devices), and backed up to your dropbox. Firebase is for auth (e.g. for us to know who you are, manage subscription etc). None of your financial data is kept there. We don't have a decent way to set up and track subscription without that central piece (firebase).
In other words, when the company goes down, there are two concerns:
1st whether you will have access to your data. Yes, and no one else has access to it.
2nd whether you will be able to use the app. We plan to open-source the app when/before that happens. This part, you have to trust us. We don't see an easy way out of this, yet.
I understand your hesitation. But there are already user using it on a regular basis, who care about privacy but trust us to have the auth centralized. It's not for everyone, but it's what we plan to do, at least for near future.
I am confused this article does not talk about taint tracking. If state was mutated by an agent with untrustworthy input the taint would transfer to the state, making it untrustworthy input too, so the reasoning of the original trifecta with taint tracking is more general and practical. I am also also investigating the direction of tracking taints as scores rather than binary as most use cases would otherwise be impossible to do at all autonomous. Eg. with sensitivity scores to data, trust scores to inputs (that can be improved by eg. human review). One important limit that needs way more research is how to transfer the minimal needed information from a tainted context into an untainted fresh context without transferring all the taints. The only solution i currently have is by compaction and human review, if possible aided with schema enforcement and optimised UI for the use case. This unfortunately cannot solve encoded information that humans cannot see, but it seems that issue will never be solvable outside alignment research.
PS: An example how scores are helpful: Using browser tab titles in the context would by definition have the worst trust score possible. But truncating titles to only the user-visible parts could lower this to acceptable for autonomous execution if the data was just mildly sensitive.
Have you seen the DeepMind CaMeL paper? It describes a taint tracking system that works by generating executable code that can have the source of data tracked as it moves through the program: https://simonwillison.net/2025/Apr/11/camel/
Of course. CaMel was a breakthrough and especially promising as similar execution architectures were discovered from the reliability angle too (eg. cloudflare code-mode)
I would consider the runtime and capabilities part of CaMel an implementation exploration on top of the trifecta + taint tracking as general reasoning abstraction.
My hope was that there would be an evolution of the the more general reasoning abstraction that would either simplify or empower implementation architectures, but instead I do not see how metas rule of two adds much here over what we already had in April. Would have loved for you to add one sentence why you thought this was a step forward over taint tracking, maybe i am just missing something.
Totally. I think the original "Lethal trifecta" post by OP only pertained to data exfiltration and never included changing state (maybe was implied by sensitive data access).
Can you explain what you mean? How is Chesterton's fence applied to AI security helpful here? Are you just talking about not removing the "Non-AI" security architecture of the software itself? I think no one ever proposed that?
Right, what got me going is the reduction of plenty cyber security concepts into a simple "safe" label in the diagram.
So what I meant is that before you discard all of the current security practices, it's better to learn about the current approach.
From another angle, maybe the diagram could be fixed with changing "safe" to "danger" and "danger" to "OMG stop". But that also discards the business perspective and the nature of the protected asset.
I am also happy to see the edit in the article, props to the author for that!
And to address the last question, no one proposed that right now, yes. But I was in plenty of discussions about security approaches. And let me tell you, sometimes it only takes one sentence that the leadership likes to hear to detail the whole approach (especially if it results in cost savings). So I might be extra sensitive to such ideas and I try to uproot them before they bloom fully.
Hmm, what do you mean by current approach? This is new territory and agent safety is an unsolved problem, there is no current approach, except you mean not doing agent systems and using humans. The trifecta is just a tool on the level of physics saying "ignore friction", we assume the model itself is trustworthy and not poisoned most of the time too, but of course when designing a real world system you need to factor that in too.
Yes, by current approach I mean security best practices for non-LLM apps. Plenty of those are directly applicable.
And yes, LLMs have some challenges. But discarding all of the lessons and principles we've discovered over the years is not the way. And if we need to discard some of them, we should understand exactly why they are no longer applicable.
EDIT: I know that models need to omit stuff to be useful. But this model omits too much - claiming that something is "safe" should be a red flag to all security workers.
Hot module replacement masks a lot of annoyances for end users. Yes its more instantaneous than reloading a page and relying on urls for all of the state and I am not advocating hard for abolishing HMR anymore, but it would be nice if we still used way more url state than currently the case. Browsers will also hibernate tabs to varying degrees, server sessions expire all the time, things are not shareable. The only thing that works as users expect is url state. One thing i absolutely hate about ios apps is how every state is lost if i just have the app in the background for a few seconds, this even applies to major apps like youtube, google maps, many email clients etc. Why do we live in this stupid world were things are not getting better, just because someone made things more convenient for developers?
PS: and i curse the day the social media brainwashed marketing freak coined the term "deep link" to mean just a normal link as its supposed to work.
reply