Agree to disagree. I am enthusiastically waiting for Asahi to sort out its display and power management issues, after which I am instantly switching. I'd even take Win 11 over the dumpster fire that is MacOS Tahoe and I am not the only one who uses is begrudgingly amongst my colleagues.
Slightly off-topic but this is why 3D printing becoming popular is a boon to the repair industry. Yeah, the part might be bad, but instead of paying a ridiculous sum for a piece of plastic, you can take the old one, model it, and make yourself a compatible one within a day. Of course, this requires modelling skills and the ability to be able to disassemble the machine but so does any other kind of repair work and at least you are no longer reliant on the manufacturer.
3D printing is pretty neat. I've printed some functional widgets that work well. I can just download the things and then print them, and that's awesome.
I don't know if I'd to be printing a replacement gear for a washing machine, though. The original was probably injection-molded nylon, which is a quite good combination of accurate repeatability and robustness, and presumably had good material compatibility with the other gears.
But despite those advantages, this original part already failed.
Whatever I can print is going to be sloppier and weaker, with a less-compatible material and in a less-compatible shape. If the first part failed because it was underspecified, then this printed part is going to be even less reliable.
Someone with appropriate skills could use that as a set of constraints to design an entirely new (probably physically larger) gearbox that is superior to the original, but that's sounding like Real Design Work. And iterating on design and in-situ testing means taking apart and reassembling a washing machine -- again.
I hate taking apart washing machines. It's awful work.
It seems like it'd more fun to spend $150 on a new gearbox that will probably fail every few years than to iterate on 3D printed washing machine parts at home, but perhaps my proclivities are poorly aligned. :)
Not only that but it's also quite difficult to find a laptop with an ANSI keyboard in an ISO country. My choices are basically an overpriced new Macbook (MacOS is the main con here), an overpriced new Thinkpad (brand new ones are horrible value since it tanks just a year after purchase), a Clevo (much worse build quality and questionable Linux support), or a Framework (worse build quality and mediocre battery life). As much as I hate MacOS, my M1 Macbook is still better at just being a light machine I can take anywhere and be working with immediately, while still lasting over an entire workday regardless of what I do. I really wish that Lenovo would fix their X9 Gen1 Linux support as those laptops are basically what I'd run if I could have proper support.
I have a Pixel 8 running GrapheneOS and it does most of the above:
- slightly lesser build quality than my iPhone 15 Pro but comparable
- doesn't funnel data to Google unless you explicitly let it, you can circumvent a lot of the Google Play stuff by restricting permissions and using Aurora Store
- is backed by, well, Google and the Graphene team porting over security updated. They have a fairly good track record by now.
- can use any of the N backup services that already exist unlike the iPhone's silly restriction on background apps
- don't notice performance differences between it and my iPhone 15 Pro in day to day use. If anything, biometrics are way faster on the Pixel since iOS 26 made FaceID slow as molasses for me
- the default camera is pretty good (uses all the Pixel fancy processing hardware) but if it's not good enough you can just install the stock Google camera which works fine. You can turn off network access if you don't want it snooping. Photos are neck and neck with the iPhone but the iPhone is way better at videos, no Android phone has cracked that yet IMO.
- Yeah, but no other brand can give you an AppleCare experience. Best option is phone insurance and just getting a new Pixel if that happens. Graphene can do full device backups via Seedvault and it's not that much more of a pain to restore compared to an iPhone backup. Granted, it's jankier but it's not impossible. The other issue is that Pixels are not a thing in a lot of countries, Apple really has the edge here but I'd take that risk over the UX shenanigans they pull nowadays with their latest updates (god is it awful)
LTT did a video on GrapheneOS recently[0]. The conclusion was basically that it’s a trade off between privacy and convenience. It will require more tinkering and things that don’t “just work”. While I haven’t used GrapheneOS, it doesn’t seem like something a non-technical user would have the patience for, unless they were into the idea of picking up a new hobby of managing their phone’s OS.
The way it works is the user registers / imports MCP (Model Context Protocol) servers they would like to use. All the tools of those servers are imported and then the firewall uses structured LLM calls to decide what types of action the tool performs among:
- read private data (e.g. read a local file or read your emails)
- perform an activity on your behalf (e.g. send an email or update a calendar invite)
- read public data (e.g. search the web)
The idea is that if all 3 types of tool calls are performed in a single context session, the LLM is vulnerable to jailbreak attacks (e.g. reads personal data -> reads poisoned public data with malicious instructions -> LLM gets tricked and posts personal data).
Once all the tools are classified the user can go inside and make any adjustments and then they are given the option to set up the gateway as an MCP server in their LLM client of choice. For each LLM session the gateway keeps track of all tool calls and, in particular, which action types are raised in the session. If a tool call is attempted that raises all action types for a session, it gets blocked and the user gets a notification, which sends them to the firewall UI where they can see the offending tool calls, and decide to either block the most recent one or add the triggering "set" to an allowlist.
Next steps are transitioning from the web UI for the product to a desktop app with a much cleaner and more streamlined UI. We're still working on improving the UX but the backend is solid and we would really like to get some more feedback for it.
That is a fair concern, and while that would happen often in some cases, there are others which rarely export data or rarely read public data where you can manually approve each usecase. Still, we are very interested in seeing how people use MCPs so we can improve the UX, which is why we're publishing this release. If users report that they get too many false positives we can always increase the granularity of the trifecta categories (say, exports data can be exports data publicly or privately. Or reads public data can have different tiers, etc.)
It is based on what the MCP server reports to us. As with most current LLM clients we assume that the user has checked the MCP servers they're using for authenticity.
Really good questions, let's look at them one by one:
1. We are assuming that the user has done their due diligence verifying the authenticity of the MCP server, in the same way they need to verify them when adding an MCP server to Claude code or VSCode. The gateway protects against an attacker exploiting already installed standard MCP servers, not against malicious servers.
2. That's a very good question - while it is indeed non-deterministic, we have not seen a single case of it not showing the message. Sometimes the message gets mangled but it seems like most current LLMs take the MCP output quite seriously since that is their source of truth about the real world. Also, while the message could in theory not be shown, the offending tool call will still be blocked so the worst case is that the user is simply confused.
3. Currently we follow the trifecta very literally, as in every tool is classified into a subset of {reads private data, writes on behalf of user, reads publicly modifiable data}. We have an LLM classify each tool at MCP server load time and we cache these results based on whatever data the MCP server sends us. If there are any issues with the classification, you can go into the gateway dashboard and modify it however you like. We are planning on making a improvements to the classification down the line but we think it is currently solid enough and we would like to get it into users' hands to get some UX feedback before we add extra functionality.
Those are really good points and we do have some plans for them, mainly on the first topic. What we're envisioning in terms of UX for our gateway is that when you set it up it's very defensive but whenever it detects a trifecta, you can mark it as a false positive. Over time the gateway will be trained to be exactly as permissive as the user wishes with only the rare false positive. You can already do that with the gateway today (you get a web notification when the gateway detects a trifecta and if you click into it, you get taken to a menu to approve/deny it if it occurs in the future). Granted, this can make the gateway overly-permissive but we do have plans on how to improve the granularity of these rules.
Regarding the second point, that is a very interesting topic that we haven't thought about. It would seem that our approach would work for this usecase too, though. Currently, we're defending against the LLM being gullible but gullible and actively malicious are not properties that are too different. It's definitely a topic on our radar now, thanks for bringing it up!
reply