gnl

I don't know, but if there were, I wouldn't expect them to do anywhere near as good a job or – perhaps somewhat counterintuitively – be anywhere near as reliable. Static rules only go so far when it comes to this stuff. And assuming that you're starting from a trustworthy base, and Claude Code (or similar) can focus its attention on recent changes to the repo in particular, I imagine sneaking actual malware in there would be pretty hard without throwing up a bunch of red flags.

See also:

- [0-Days \ red.anthropic.com]( https://red.anthropic.com/2026/zero-days/ )

EDIT: The main challenge here is more likely to be the noise, as the LLM is more likely to flag too much than too little, so I'd recommend putting together a prompt that has it group whatever it finds by severity and likelihood of malicious intent.

EDIT 2: Re Anthropic link above – worth pointing out that finding intentionally introduced malware when you have access to the source code and git history is a hell of a lot easier than finding a 0-day. The malware has to exfil data eventually or do ransomware stuff, good luck hiding that without raising the alarm, plus any attempt at aggressive obfuscation will raise the alarm on its own. I'm not saying it's impossible, I am saying that I think it's very very hard.

Yeah that one's too much for me too, I used to do this years ago, but not anymore. Especially since I found out Brave supports network blocking for extensions, which is something you generally set up once and then forget about it. I'm just giving people tools and ideas I didn't see mentioned elsewhere in the comments, it's up to everyone to figure out their particular threat scenarios and tradeoffs individually.

This could probably be automated though if someone wanted to tackle it. git pull, agentic code review, auto-build from source, install.

Couple of quick thoughts on how to protect yourself from having a formerly trustworthy extension go rogue on you:

- https://github.com/beaufortfrancois/extensions-update-notifi...

And then you can do whatever you feel is an appropriate amount of research whenever a particularly privileged extension gets updated (check for transfer of ownership, etc.)

- brave://flags/#brave-extension-network-blocking

You can then create custom rules to filter extension traffic under brave://settings/shields/filters

e.g.:

  ! Obsidian Web
  *$domain=edoacekkjanmingkbkgjndndibhkegad
  @@||127.0.0.1^$domain=edoacekkjanmingkbkgjndndibhkegad

- Clone the GitHub repo, do a security audit with Claude Code, build from source, update manually

Thank you! "Dead simple and super effective" is pretty much exactly what I was going for, so this is great to hear. If you ever find yourself using `pprint` debugging for any other reason than having forgotten that Playback exists, I would consider this a failure on my part and would very much appreciate an open issue or a message on the Clojurians Slack.

Would you care to elaborate and point to some specific features and workflows that you consider to be unique to the real Vim?

This is spot-on. In a perfect world every major OS would have proper, granular mandatory access control enabled by default and applications would come with a profile specifying precisely which resources they require – at least regarding the more critical stuff like keys and cookies – with attempts to access anything else triggering an optional notification. Hopefully macOS will become more granular that way and Apple will continue pushing and improving what they began with Catalina.

Meanwhile, in a less than perfect world there's XFENCE [0], previously known as LittleFlocker. It's basically LittleSnitch for files. It was originally developed by Jonathan Zdziarski and later sold to F-Secure.

The challenge is to set it up in such a way that the level of interaction is kept at a minimum while still providing some level of protection.

I might write a detailed blog post / howto about it, but meanwhile here's the TL;DR if someone wants to try this blacklist/greylist approach:

1. Set an 'Allow any app – rwc' rule for /Users to override the default 'Watch – rw' rule there, which would otherwise result in a ton of popups. This does not override the more specific watch rules for some critical resources like loginitems, etc.

2. Add watch rules for additional critical resources, like ~/.gnupg, ~/.ssh, ~/bin, possible password manager directories, Firefox/Chrome directories to prevent cookie extraction, etc.

3. Temporarily add a watch rwc rule for ~/, thus overriding the Allow rule for /Users.

4. Run any network connected software with a potentially large attack surface like browsers, torrent clients, vpn clients, etc. and give them the required permissions to your home directory using the popups. Make sure to put them through their paces in terms of file system access to cover all possible use cases.

5. When they are usable without any more popups, remove the temporary watch rule and add 'Deny rwc to /Users' rules for each one, thus overriding the general /Allow rule we created above. An application-specific watch rule would be nice here instead, but sadly that doesn't seem to be possible – watch rules apply to all applications.

Execute steps 3–5 for any other untrusted software you might want to install/run.

When combined with LittleSnitch to catch possible attempts at data extraction, this reduces the risk of rogue applications extracting/damaging critical data and limits the potential damage of possible RCE vulnerabilities in network connected software. And it does this with a minimum of interaction – after the initial setup phase.

I've been running LittleFlocker/XFENCE for a couple of years now and the setup described above for maybe a year and it works like a charm, currently on Mojave, previously High Sierra, all the way back to Capitan, if memory serves.

A whitelist approach would of course be more secure, but that's way too stressful and distracting for me.

[0] https://community.f-secure.com/t5/Home-Security/XFENCE-beta-...

Slightly off-topic, but no argument for colonising Venus could possibly be complete without digging this gem of a comment out of the archives about cooking a turkey there: http://www.transterrestrial.com/2013/12/09/venerian-gas-phas...

Much as I love Clojure, I agree that clojure.spec, while very powerful, has a mess of a UX. That's why – shameless plug – I wrote Ghostwheel [1], which, to me, turns it into a whole other thing, especially when gen-testing, spec-instrumentation and tracing are used together.

Having inferred types in addition to this would be even better, but types are no replacement for generative testing or vice versa.

They really complement each other quite nicely, but also have a large overlap in terms of how much they can reduce the need to do manual debugging and enable clean changes/refactorings with minimal effort.

[1] https://github.com/gnl/ghostwheel

clojure.spec+generative testing help a lot, but yeah.

Have some monads and stuff: http://funcool.github.io/cats/latest/#maybe

Author of Ghostwheel here – clojure.spec is certainly not a replacement for static typing, but it goes a long way to covering many of the same use cases, in fact longer than one might think at a cursory glance.

With Ghostwheel you write your function specs similar to how you'd write a type signature and you get automatic generative testing (including higher order function support) and side effect detection which – when combined with spec instrumentation (+ the upcoming evaluation tracing for the test execution) – can often tell you quite precisely where you screwed up in a much more immediate and granular manner than a simple unit test or mucking about in the REPL could. It really is a quite different experience from plain Clojure.

That being said, I'd love types in addition to this and I'm keeping a keen eye on ReasonML.

While that is true of the basic building blocks of the language, clojure.spec for example does have an overly verbose syntax (I would define it that way, even though it doesn't introduce new basic syntax elements) for function specs and that was one of the main motivations for writing Ghostwheel.

I wouldn't see this as some sort of development in Clojure though and I don't really know if that's what cutler meant anyway. Maybe he'll elaborate.

That is certainly a fitting username. Thank you!

The font in the screenshots with the ligatures is in fact Fira Code and the font in the REPL screenshots without ligatures is Ubuntu Mono.

I guess those could be considered additional syntax, but they're also completely optional and interchangeable with the corresponding, more Clojure-like keywords.

The short answer is "more or less", the longer answer is the second one in the FAQ:

https://github.com/gnl/ghostwheel#faq

When you place the cursor on >fdef or >defn – which Cursive doesn't know what to do with out of the box – a light bulb appears right next to it. This is IntelliJ's quickfix feature for errors it can easily correct. You click it, select 'Resolve as...' and then 'defn'. I think the default shortcut ist Alt+Enter.

EDIT: I'll update the docs to make this clearer.

At the moment you can set the gspec to nil, but that would simply disable s/fdef generation and all of the spec-related magic. I'm planning to introduce a configuration option with the next release to force Ghostwheel to trust that there's an external s/fdef for that function and still do all the spec stuff.

There may be some limitations on this compared to using inline gspecs – I have to play around with it a bit, but I think it should work fine. Until then, you can still use Ghostwheel for tracing and side effect detection though.

This is basically generative testing using clojure.spec in a nice package with a cherry on top and a few extras.

core.typed still seems to be quite experimental and not yet production-ready, but it certainly looks very promising and I'm keeping an eye on it. It currently also doesn't work on ClojureScript, which has been the primary platform for Ghostwheel so far.

Fellow Clojurians, I present to you, Ghostwheel.

It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros.

It's Alpha software and the Clojure port, while essentially functional, still needs some love to achieve full feature parity with ClojureScript – most prominently missing at the moment is the tracing functionality.

To steal a quote from Nathan Marz' Specter in a blatant attempt at a so far likely undeserved comparison to its indispensability, I like to think of Ghostwheel as clojure.spec's missing piece. It has become quite essential to me and I hope that you will find it useful too.

Feedback, PRs, and issue reports are welcome and much appreciated.

Do your thing, HN.

Project North Star from Leap Motion seems like an affordable DIY solution if you don't mind getting your hands dirty.

http://blog.leapmotion.com/north-star-open-source/

That looks like it might easily involve lots of fiddling, tweaking and dealing with obscure issues while XFence just works, which is worth a lot to me these days.

Not that I know of. The only other comparable project I'm aware of (including relative ease of use as a criterion here) is Linux' AppArmor.

> All of those are the same thing: defenses. Abstractly, they are fears of finality. Not finishing means anything can still happen, your identity remains intact: "I'm a writer."

> More concretely, they are a form of self doubt not about the success of executing the act which is in your control-- the writing of the book, the asking the girl out-- but of being able to manage the consequences which are not-- the publishing of the novel, sustaining a relationship/finding a burn unit.

Brilliant article. Hits home. Thanks.

I would love to have some sort of L(onger)TS release. I'm perfectly happy with how my system is set up, everything just works, I don't need new features and I'm dreading the next upgrade forced on me by the loosely defined (or not at all really) and rather short EOL cycles.

Yup. While I do need to use a number of third-party tools to get the UX like I want it (Hammerspoon, Hyperswitch, Spectacle and Quicksilver), they do exist, they work fine and I think this has more to do with my specific requirements than with any fundamental issues or missing features in the UX.

Going forward, advanced sandboxing is indeed one of the most important things that I would love to see Apple focus on. Ever since I first considered the possibility that apps can have individual access controls, probably around the time I first encountered SELinux/RSBAC and later AppArmor, I've been wondering why vendors aren't pushing this as an absolute top priority on the security front.

Meanwhile I'm using this:

https://beta.f-secure.com/key/XFence

It's Jonathan Zdziarski's Little Flocker rebranded after he sold it to F-Secure. It works great, but it does admittedly require an upfront investment.

2 caveats:

- Current version only works on Sierra (I'm not touching High Sierra until just before the next one comes out)

- Creating "any via" rules can lead to noticeable slowdowns, while "ancestor" rules, even though they are theoretically more expensive, don't (unless one overuses them, I suppose). It's probably a bug.

Other than this, I've been using it for over a year and have no complaints whatsoever.

I'm currently in a somewhat similar situation, although with a smaller open source project, and that's exactly what I've been struggling with the last few weeks. There are some great points in the comments here, here are my 2 cents and what I'm currently doing.

Like someone here said already - the second 90% are no fun. The first 90% are fun, launching is fun, people using and loving your software is fun and eventually getting filthy rich is probably fun (I really wouldn't know), but the second 90% are usually just a giant pain in the arse. Accepting that does make it easier.

Plus, when you're making something you care about and you really want it to be good, it's particularly hard to say no to features, even more so when you expect to get paid for the whole thing. And a case can certainly be made that one should probably be careful not to launch an MVP with too strong an emphasis on the M, no second chance for a first impression and all that.

That being said, as Joel Spolsky once wrote, shipping is a feature. It's your most essential feature. If you cut a few things here and there and add them post-launch, it probably won't kill you. It may even turn out that you don't need them or that you could do them better.

If you keep pushing a deadline trying to get everything in there, getting it just so for the launch, losing more and more motivation along the way, maybe deciding that you really need to rewrite this or that but it'll take you another month or something - that could kill you.

So I think this is the time to brutally cut everything you can cut and just get the damn thing out the door. Half a product is better than both a half-arsed product and no product.

Once you're done butchering your todo list, you apply the age old universal recipe for all things that you don't feel like doing but need to do, trite though it may seem - you take it one step at a time. You don't sit down at the computer thinking "I've got to launch this". You sit down thinking "I've got to implement this thing", "I've got to fix that bug", etc.

You've worked on something continuously for two years. This already puts you ahead of the overwhelming majority of people who want to make things. In the words of Captain Reynolds:

https://youtu.be/xbbj2o0yUI0?t=17s

I should probably go and see about following my own advice now.

> Don’t make the mistake of arguing that knowing a second language has many benefits. The point is that foreign language instruction in schools doesn’t teach a second language.

Here he seems to be making the argument that it just doesn't work rather than that it's not worth it. At the same time, Bryan Caplan whom he quotes and seemingly endorses, is arguing that it's not really worth it.

Not quite sure what to make of this other than that both points strike me as equally ridiculous.

Foreign languages absolutely /are/ worth it, even if one is lucky enough to be born in an English-speaking country, and saying that second language education should be dropped because it doesn't work is absurd.

Language education certainly needs to be improved all over the world. There is enough research and anecdotal evidence that clearly shows that the standard language education with a focus on learning grammar and doing 'fill in the missing word' exercises from day one is largely a waste of time as opposed to a focus on listening comprehension and learning whole phrases and sentences in context and with relevant material one has a genuine interest in.

For example I find there's a strong correlation between English movies being subtitled (Netherlands, Nordic countries), as opposed to dubbed (Spain, France), and general English levels in the population.

As for the 'hardly any jobs use foreign languages' argument - that really is quite disturbing, but in a way also very honest at the same time. The goal of school isn't to help children develop into self-determined fully-formed adults but rather to produce economically useful human resources.

Learning different languages enables one to view and conceptualise the world differently. There's a strong indication that being multi-lingual reduces the risk of Alzheimer's and dementia. A second language opens up a whole new world, culture, literature in a way that consuming translated material simply cannot provide.

Last but not least, it seems to me that there's a frighteningly large number of Americans whose worldview is more or less that North America is the cradle of civilisation, Europe is this quaint little village where you can go on holiday and the rest of the world is basically a shithole, to paraphrase our beloved leader of the free world.

In my opinion being exposed to a different culture/world from an early age through an improved language curriculum focusing on immersion in real world material can absolutely have a positive effect on this and in that context also help improve the current political discourse, which, to butcher a quote from John Oliver, mostly boils down to "two people who don't know what they're talking about, being condescending to each other until one of them eventually manages to land a sick burn". Who knows, if more people had a better idea of what the world actually looks like outside of their own borders, it might even become a little harder for the US to keep spreading all that democracy around it.

Sorry about the rant, this sort of thing really gets me going.