nrr

It seems you're right. I'm thinking of the third-party APNs (why does Apple insist on the lowercase "s" here?) server providers who do sometimes bill on a per-notification basis.

I'll admit that I know basically nothing about how this ecosystem works in 2024, particularly as it relates to push notifications from self-hosted applications as Zulip can sometimes be.

I suspect that the cost for push notifications might have to do with the costs imposed by Apple and Google for their respective OSes' notifications backends, but don't quote me on that. The $3.5/user/month smells like a way to recoup that kind of cost without making it overly burdensome for folks within one standard deviation of the mean.

That said, it appears that XMPP might be workable here: eJabberd is still actively maintained, and there are mobile clients (namely, Monal for iOS and Conversations for Android) that appear to support push notifications. Given your talk of self-hosting, I feel comfortable recommending something that requires some degree of system administration investment.

If you're coming by after the fact and scratching your head at what a data diode is, Wikipedia's page on the subject is a decent crib document. <https://en.wikipedia.org/wiki/Unidirectional_network>

There are also many of us who have family in the US since the 1860's and still speak (Alemannic) German at home and in the surrounding community.

This also goes notwithstanding the indigenous peoples, whose Diné bizaad and Tsalagi, for example, are also spoken here.

I am, in fact, not an engineer; I trained to be an actuary. (Though, I guess if one squints enough, the operations research electives look like industrial and systems engineering.)

I consider UBI less an engineering exercise with requirements that feed into the engineering method and more one of ratemaking and claim severity against an entire trade system. My only goal is to put a dollar amount on a loss event (and get some quantification of how many loss events occur over time while we're not looking). What anyone does with that is up to them.

Use of the second person was certainly a choice.

I'll be honest. You had me in the first half, but then: "... the hypothetical paradise it produces full of wonderful artists and musicians and programmers creating text editors rather than CRUD apps ..."

Who willingly endeavors to write text editors in 2024 when acme(4) exists?

I jest. More seriously though, if the measure of one's value to society is in their ability to crank out CRUD apps, I'm appalled. I want more dishwashers, more plumbers, more framers, more joiners, more cooks, more babysitters, more stonemasons, and the only way any of that kind of hard labor is sustainable is if there's a cushion to fall back on to recuperate. Bodies break. They break more catastrophically when the damage is continued and sustained over time.

I want my girlfriend to feel free to take on domestic work full-time with the knowledge that, no matter what, she'll be paid for it and that her domestic labor contributions, as informal as they are, are valued monetarily without my having to make up the balance. Likewise, I want that there in case I myself want to take up those domestic responsibilities for a while.

These are two cohorts that literally cement the foundation of society, let alone our trade system, not a cavalcade of keyboard cowboys wrangling Ruby on Rails. I want UBI for them because, without them, the entire project literally crumbles.

It's my understanding, having done benchmarks on file access on Windows, that NTFS itself is not the problem. It's old, but the revision of the on-disk structure that we use today hails from Windows XP, and it's about on par in terms of feature parity (and backwards compatibility, given that I can still read native NT 3.51 volumes on Windows 11) with ext4.

A lot of the weirdly bad performance comes from all of the machinery that Windows wraps around file access for things like filter drivers. As long as you don't, say, indiscriminately follow every CreateFile() with a CloseHandle() and instead treat handle closure like garbage collection, you can actually eke out pretty good performance.

That all said, yeah, Windows containers are less than great for what I'd argue is one strikingly glaring flaw: Docker container images are built from smss.exe upward. That makes them not immediately portable between ntoskrnl.exe releases.

No, I've never worked for Cisco, but I did have my own firewall product at one point. (: That's another story for another day though.

Plan 9 is, at its core, still an ambient authority system, and I will never try to misrepresent it otherwise. That said, I've found it does an admirable job emulating what a "familiar" (in the sense of not looking completely alien to someone who only knows ambient authority) object-capability system could look like, kind of like how you can emulate the free monad in Ruby despite it not being a functional programming language.

This is possible principally because the mantra of Plan 9 is that everything is a filesystem: if you can bind it into your namespace, you can access it. As a corollary, if you can't bind it into your namespace, you can't access it. It makes shaping one's ambient authority a remarkably productive endeavor.

Yeah, that was the subtext that I left unsaid through this. rfork(RFNOMNT|RFCNAMEG) got you both a completely clean namespace and a namespace that denied additional mounts (as well as dereferencing pathnames beginning with #, as in #s).

The Plan 9 primitives were refreshingly simple and consistent.

I strongly suspect that a good GUI implementation will look like how file choosers on RISC OS work, and the command line environment might be inspired by both Plan 9's namespaces and how data definitions (and their accompanying data control blocks) work in JES2 JCL on MVS.

My only concern is that, without well-thought-out access controls, the only people who will care will be nerds or folks with a high frustration tolerance for poorly-considered human-computer interaction.

"but can you even pass a file descriptor across a file descriptor in plan9 the way scm_rights lets you do in bsd and linux?" No, the mechanism was even simpler. We had the #s device (usually bound as /srv) for this, whereby you could drop a file in /srv containing a single integer representing a file descriptor, and other processes could open() that file to get another reference to that file descriptor.

My mandatory access control experiments abused the fact that I could have open file descriptors and barely anything bound in the namespace by the time I exec()ed what I wanted to run. What files did those file descriptors reference? You didn't need to know, and you couldn't see them.

Right. On Plan 9, this kind of composition usually took the form of rfork()ing to inherit the parent process's namespace, mutating it in a handful of ways deemed useful, and then exec()ing the new image. The mechanics are clear to me, I feel.

What isn't clear are the logistics: what, concretely, do we need to undertake in order to avoid a security posture lateral step from ambient authority to object-capabilities? Importantly, how do we make this ergonomic?

My experience with this on Plan 9 (while not an object-capability operating system, it gets IMO most of the way there in the ways that matter in order to experiment) was that it worked a treat for long-running services, but it was a little hard to make ergonomic for the end user sitting at a terminal.

I played with augmenting factotum with a form of mandatory access control, whereby I could ask the hostowner's factotum to mount and bind things into a freshly rfork()'d namespace on an as-needed basis, but the feeling was that it could build up access delegation fatigue pretty quickly.

The thing that still puzzles me is how we determine which workload gets which capabilities.

On Plan 9, I took a lot of glee in rfork()ing my way into a tightly curated namespace that disallowed subsequent use of mount and bind, but that was a deliberate decision under the philosophy of the principle of least privilege. Is that the other half of what you're after?

Sorry, I was imprecise. If a principal starts a new process that indiscriminately inherits the same capabilities of its parent, the security posture is no different from what we have today.

I don't disagree that the prevailing ambient authority model is less than ideal, but I'm left scratching my head at how capability security would solve the more acute problem we're facing.

Of particular note, the kinds of ransomware compromise that lead to organizations asking underwriters to sell them cybersecurity insurance policies wouldn't immediately be thwarted by moving to capabilities. If a principal has valid requisite pointers to the resources they need to do their job, they have valid requisite pointers to the resources that a cryptolocker needs to cause disaster. It's those cybersecurity insurance policies (or regulatory frameworks, where those exist) that ultimately drive the decisions to implement EDRs.

As someone who straddles the Austrian and Swabian ways of doing things, if I had to pinpoint the true underlying German fetish, it's one of avoiding risk. The bureaucracy and obsession with paper-based processes really do stem from that.

I haven't looked too deeply into how EDRs are implemented on Linux and macOS, but I'd wager that CrowdStrike goes the way of its own bit of code in kernel space to overcome shortcomings in how ETW telemetry works. It was never meant for security applications; ETW's purpose was to aid in software diagnostics.

In particular, while it looks like macOS's Endpoint Security API[0] and Linux 4.x's inclusion of eBPF are both reasonably robust (if the literature I'm skimming is to be believed), ETW is still pretty susceptible to blinding attacks.

(But what about PatchGuard? Well, as it turns out, that doesn't seem to keep someone from loading their own driver and monkey patching whatever WMI_LOGGER_CONTEXT structures they can find in order to call ControlTraceW() with ControlCode = EVENT_TRACE_CONTROL_STOP against them.)

0: https://developer.apple.com/documentation/endpointsecurity

Yeah, that's about right.

The most insidious part of this is when there are entire swaths of infrastructure in place that circumvent the usual code review process in order to execute those configuration changes. Boolean flags like your `config('foo')` here are most common, but I've also seen nested dictionaries shoved through this way.

Writing from the SRE side of the discipline, it's commonly a configuration change (or a "flag flip") that ultimately winds up causing an outage. All too seldom are configuration data considered part of the same deployable surface area (and, as a corollary, part of the same blast radius) as program text.

I've mostly resigned myself today to deploying the configuration change and watching for anomalies in my monitoring for a number of hours or days afterward, but I acknowledge that I also have both a process supervisor that will happily let me crash loop my programs and deployment infrastructure that will nonetheless allow me to roll things back. Without either of those, I'm honestly at a loss as to how I'd safely operate this product.

Pay for what exactly though? Cybersecurity incidents result in material loss, and someone somewhere needs to provide dollars for the accrued costs. Reputation can't do that, particularly when legal liability (or, hell, culpability) is involved.

EDR deployment is an outcome-modifying measure, usually required as underwritten in a cybersecurity insurance policy for it to be in force. It isn't itself insurance.

Not likely, not unless the disk is also not BitLockered.

Here you go. <https://www.reddit.com/r/crowdstrike/comments/1e6vmkf/commen...>

I don't have a technical writeup to offer, but your assessment around the BSOD seems correct enough. Without having an affected machine but knowing how NT loads drivers like this, I'd hazard a guess that the OS likely isn't even getting to the point where smss.exe starts before the kernel bugchecks. This means no userspace, which almost certainly means no hope of remotely remediating the problem.

Not quite. Insurance is a product that provides compensation in the event of loss. Deploying CrowdStrike with an eye toward enterprise risk management falls under one of either changing behaviors or modifying outcomes (or perhaps both).

"Too bad TimApple has no sense of how to do anything other than chase growth …" I feel like this is more emblematic of the wider industry trend than Apple's own strategy that they chose to impose on us.

The focus shifted very hard over the past 15-20 years from selling people new and novel gadgets and software to turning us ordinary folks into "monthly active users." Personal computing got a lot less personal, and Apple leaned into it to stay relevant.

I would argue that understanding the pathological behavior in something is critical to developing an accurate intuition for it, yes. These cases don't show up often, but when it comes to having a good sense of smell for when part of a proof is flawed, it really helps to have that olfactory memory.

This is true (i.e., the struggle is productive) only if the struggle allows for students to develop the intuition of the subject required for synthesis.

Even then, before you get to that point, you have to prime students for it. Throwing them into the deep end without teaching them to float first will only set them up to drown. This does typically mean lots of worked motivating (counter-)examples at the outset.

It's a big reason why we spent so long on continuity and differentiability in my undergraduate real analysis class and why most of the class discussion there centered on when a function could be continuous everywhere but nowhere differentiable. Left to our own devices and without that guidance, our intuition would certainly be too flawed for such a fundamental part of the material.

One person's heresy is another person's sickos.png. This sounds exactly like my favorite sort of object code vivisection.

The odd part is that, at its core, Windows still is file-based. Managing it isn't, but anyone who's gone digging around in NT's Object Manager will be familiar with using CreateFile() to get a handle for manipulating things there.

It's, in fact, pretty pervasive when interacting with Windows programmatically, just as it tends to be on Unix-alikes, and the fact that PowerShell doesn't do well to acknowledge that is frustrating. (Worse, Windows is a better Plan 9 of sorts with MIDL and COM everywhere, and PowerShell falls pretty flat here too compared to the experience of, say, slinging a dynamically generated command stream directly at fossilcons.)

Yes, I could break into C# or C++ for this, but that takes the tasks that rely on these operations firmly out of the hands of paraprogrammers.