[fingerlocks]

It’s not in a public header. You can easily snoop “private” properties and methods quite easily in Objective-C, because the concept doesn’t exist. It doesn’t exist in C either, but if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.

[friendzis]

> if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.

So we are talking about public/private access specifiers in source code, which only matter in cooperative setting. But that's IMO highly naive view as compute, especially OS, is objectively an adversarial environment. Some actors, at some point WILL figure out the memory layout and use that in an attack. There have been literally decades of whack-a-mole against bad actors.

I maintain my stance that any fields/members/methods loaded into a userspace program should not be capable of breaking the system.

[atonse]

People using private APIs know that they might cause instability (in their apps usually). That's why those APIs are private, they can change since there are no guarantees.

I'd point fingers towards the electron core devs for this one, and not devs building apps on top of electron (since they likely didn't know that's how electron was doing it).

There are cases where OS companies noticed the use of private APIs and made cleaner public ones (the most obvious was the file system syncing stuff used by Dropbox and others, which used to use private APIs until Apple provided a public one).

[eqvinox]

If you can call it, it's not private, it's that simple. Putting a "please don't call this" on is just naïve. Even in legal matters, it's already the case that laws that aren't enforced are worthless, cf. driving 5-10 mph over the speed limit being normal. It won't work any better on a weak statement on an API.

And either way, applications shouldn't be able to break the system like this. You can reasonably expect error handling to catch this, even if the error is "a private API was called".

This is on Apple. 90% at least. Maybe 10% on Electron.

[alsetmusic]

> If you can call it, it's not private

If I can walk on land that says private property, it's not private. I'll remember to use that argument when I get ticketed for trespassing.

There are APIs that are explicitly declared verboten for third-parties to use because they aren't intended for outside use. That doesn't make them magically inaccessible, but it does mean that when their unanticipated use breaks things, that's on the people who ignored the warnings.

I agree that this shouldn't be able to have the huge impact that it does and that Apple ought to have made their OS more resilient, but your logic is weak.

> Even in legal matters, it's already the case that laws that aren't enforced are worthless, cf. driving 5-10 mph over the speed limit being normal.

Just because all but one cop of the force ignore people driving over the speed limit doesn't mean the one who pulls you over is isn't able to write you a speeding ticket. Try that with a judge. It might work, but the law is very much still enforceable. This isn't like failing to protect a trademark.

[eqvinox]

> If I can walk on land that says private property, it's not private. I'll remember to use that argument when I get ticketed for trespassing.

Dude. Dudette. Duderino. Did you think this through before you hit post? I'm talking about enforcement. If you're getting a ticket, it's literally being enforced. And if it isn't, you get squatters! Thanks for the point in support, I guess?

I think this is the most braindead knee-jerk HN comment I've ever gotten as a reply, congratulations.

[Ed.: god, please, this genuinely hurts my brain.]

> but it does mean that when their unanticipated use breaks things, that's on the people who ignored the warnings.

Yeah. When it breaks things for them. Not when it breaks the entire OS' UI.

Let's stay with your analogy. Things change, Electron apps break? That's analog to finally getting around to calling the cops on squatters after dozing on it. Things change, your UI goes belly up due to Electron? That's you deciding to pay the bill for electricity and indoor plumbing for the squatters. No, wait, even better: you decided you finally want to build a new house on your plot, and now have to deal with getting the squatters out first. It'll happen, but you'll have to unnecessarily sink time and money into that. Apple's dealing with evicting Electron off their private APIs. What a nice analogy.

Of course the squatters are technically wrong. But why did you leave your front door open, and neglected and didn't check in for years? The part where you're making it hard for yourself is on you, mate. You're not going to get your lost time back. Why didn't you grab a lock at home depot?

> Just because all but one cop of the force ignore people driving over the speed limit

This is generally policy, not individual cops' discretion.

[blueflow]

rel: https://chaos.social/@equinox/115394652622711731

[eqvinox]

Indeed that Mastodon post refers to the sibling to yours. I genuinely can't bear the contradiction. My reply below is as polite as I could manage; on Mastodon there is no point in attempting to restrain my bafflement :)

[fingerlocks]

Yeah, of course they shouldn’t, but they do. Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down. DDoS for example. It’s not a solved problem.

Wax idealistic all you want, but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one. “No userland APIs, private or otherwise, should be able to crash your app!!!” Is the argument I would be responding to right now.

[friendzis]

> Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down.

> > userspace app could trigger <...> and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope

If userspace triggers what is an effectively a DoS attack and you cannot login to root terminal and get things sorted out that's a system not designed for adversarial userspace.

> but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one

A more general context we are discussing here is resource exhaustion. There are myriads of scenarios where userspace can cause some form of resource exhaustion. My argument is that a 1) well designed 2) general use system should implement resource management in a way (e.g. priority queues) that userspace-inflicted resource exhaustion does not affect performance envelope of the system itself. Otherwise the system is open to unprivileged DoS attacks with only recourse being power cycling.

If your userspace app overcommits memory to some monstrous degree, what should the system do?

1. Enter a swap feedback, crippling the system down to unusability.

2. OOM-kill a process based on some heuristics.

3. freeze userspace, leaving privileged space functional.

[fingerlocks]

I think you’re losing me. This is all completely tangential to the current discussion, bordering on non-sequitur. I don’t know why you chose to latch onto my loose quip of “bring the whole system down”, because that’s not what is happening here. I thought you knew that.

The OS got a little slower, that’s it. It was never in some unrecoverable state. One could soft close the offending processes at anytime and regain the lost perf. I’m willing to bet you could hide or minimize the window to mitigate the issue, because the bug is very specific to the layout and render run loop, which auto-pauses on lost visibility by default.

That said, I haven’t even noticed the slowdown on my work machine, but I only use Teams. it’s always been dog shit slow, just par for the course.