Often there are "abliterated" or "uncensored" tuned models that suppress the rejections. From my high level understanding it is performed by finding which weights activate for the rejection and lowering those so the model is less likely to reject.
It doesn't fix if the model doesn't know what you're asking it though (i.e. if the model never actually learned about meth production in the first place).
For those looking for mobile support connecting to remote MCP servers, I maintain a source-available chat app that does exactly that (uses OpenRouter for inference): https://benkaiser.github.io/joey-mcp-client/
Would be nice if the MCP implemented the Streamable HTTP MCP spec instead of the CLI one. I know this is already a HTTP API, but making it available as an MCP server that clients like Joey[1] can consume easily over network would be nice.
One key aspect that is missed here, is mobile users.
iOS don't have a CLI, Android phones... kinda have a CLI, but it's not really usable by all apps / universal like it is on desktop.
I've been putting together a MCP client for mobile recently [1] since to me it seems apparent that Remote MCP is a great utility but none of the major players offer it without a paid subscription.
As other commenters have mentioned, the use case here is really not for software developers, it's for everyone else. It's bringing that agentic loop to do all those "personal assistant" type things in a connected way with all of your services. We're not there yet, but maybe some day.
Am a software engineer at Microsoft using a M3 MBP, opinions are my own and all. Honestly one (of many) reasons I opted to go through the exception process to request a macbook was the screen brightness. The fact you can run software to boost the screen to HDR brightness levels for SDR content is insanely useful for working outside.
I think the parent may be referring to the fact that safari/webkit will evict all localstorage/indexeddb/caches etc after 7 days of not visiting a site. And apparently this now extends to PWAs making it a pretty big blog to building any infrequently accessed PWA that needs to persist user data locally.
Thanks for sharing, I wasn't aware of that blog post. That said, their approach sounds kind of disheartening. I love being able to use extensions within my PWAs (primarily uBlock Origin, obviously), and some Android Chrome forks (Kiwi/Mises) let me do this, while still letting me feel like I'm in a dedicated app (i.e. no browser chrome at all). The firefox team really seem to stress here that they want to keep the chrome around the app (albeit different), which really feels like it goes against the grain of what I expect a PWA to be in the first place (a chromeless website).
As a developer, the one feature I really love in Chrome is PWAs. But Firefox abandoned PWA support years ago, and seems to have no appetite for adding PWAs back[1]. Maybe I'll just have to split my usage across PWAs in Chrome (since I trust those apps/websites anyway) and Firefox for general browsing.