AbacusAvenger

Personally I have two major issues with macOS: CPU usage and bugs.

There are a ton of background services that periodically spin up for no obvious reason, consuming a ton of CPU for a few minutes at a time, then go back to idle. I don't know what they're doing or why. Luckily since they're background services, they're bound to the efficiency cores on Apple Silicon, so they don't hurt battery life or thermals too much most of the time.

And as far as bugs go, the worst part is that bug reports through the Feedback app go largely ignored and bugs seem to keep accumulating. Even for bugs with clear and well-documented repro cases, Apple doesn't seem to pay any attention.

I'm a game developer, so the majority of my bug reports come from issues I've experienced with the graphics drivers or with Xcode. Here's a few examples:

- On macOS devices with > 60Hz displays, there is some awful stuttering with Metal apps in full screen mode. For some reason, CAMetalLayer nextDrawable sometimes just takes a very long time whenever it uses direct-to-display mode for presentation. That mode is implicitly enabled for full screen Metal apps, in order to bypass the display compositor and theoretically reduce latency. This bug also applies to MacBooks with the built in "ProMotion" (120Hz) displays. I'd be perfectly happy if there was just some flag to say "don't use direct-to-display", but if there is one, it's not documented anywhere. I haven't found a workaround yet. I originally reported this in August 2022. Apple replied once in October 2022 to say "we can't reproduce this, please provide a demo app". I provided the app that reliably reproduces the problem within an hour of their reply, but they've been silent since.

- Metal and OpenGL (the latter is emulated via Metal on Apple Silicon Macs) both exhibit a bug with triangle merging that causes partial derivatives to go very wrong along primitive edges. There's a usable workaround for this on the Metal side (just enable a [[sample_mask]] even if you're not doing multisampling). There's no such workaround for the OpenGL side, unfortunately. I was able to work with Asahi Lina to fix this for Mesa on Asahi Linux, and the fix itself was actually really trivial and didn't require a sample mask hack (it took a lot of debugging to figure out, though -- but that's how reverse engineering goes). To solve it, Apple would simply need to set a particular bit to disable triangle merging whenever the fragment shader uses derivatives. I reported this issue in December 2022, and Apple hasn't replied.

- This one is not as egregious as some of the bugs I've reported, and the Xcode team has responded reliably in the past. This is the first Xcode bug report I've had where they didn't acknowledge the report within ~14 days or so. In the current Xcode beta, using the graphics debugger will suspend the app but hitting "resume" leaves the app stuck suspended. The normal application debugger path does not do this, just the graphics debugger. I reported this in mid-June 2023, but haven't heard anything yet.

Amazon would still be in charge of enforcement, they'd just be held liable for not doing so. Which is not a pleasant place to be, because blocking automation is not an easy problem, and it's difficult to measure success.

Also remember that native code can use multithreading, so if your challenge is something that could be farmed out to multiple CPU threads until one finds the solution, that's another factor in favor of native code performance.

About the benchmark data:

It looks like your pow_sha256 library is using is the "sha2" crate, which is a pure Rust implementation of SHA2. So your benchmark is around the delta of your library compiled to native code vs. your library compiled to WASM, which is an interesting benchmark but I don't think it answers the right question.

A more interesting benchmark would probably answer the question "what would those looking to defeat mCaptcha use and how does that performance compare?" So perhaps an implementation of an mCaptcha challenge solver using OpenSSL would be warranted for that.

I looked into doing something like this once and decided it wasn't going to be very effective, for a few different reasons.

JS engines (or even WASM) aren't going to be as fast at this kind of work as native machine code would be. Especially when you consider that libraries like OpenSSL have heavily tuned implementations of the SHA algorithms. Any bot solving a SHA-based challenge would be able to extract the challenge from the page and execute it using native machine code faster than any legitimate user's browser could. And if you increase the difficulty of the challenge, it's just going to punish real users running the challenge in their browser more than it would the bots.

It's also based on the assumption that proof-of-work is going to increase the cost of doing business for the bots in some way and discourage their behavior. Many of the bots I was dealing with in my case were either using cloud compute services fraudulently or were running on compromised machines of unknowing people. And they tended not to care about how long it took or how high-effort the challenge was, they were very dedicated at getting past it and continuing their malicious behavior.

There's also the risk that any challenge that's sufficiently difficult may also make the user's browser angry that a script is either going unresponsive or eating tons of CPU, which isn't much different from cryptocurrency miner behavior.

That's Numberwang. (Wordwang?)

It could be an ANGLE change responsible. I know Apple's been working on the Metal rendering backend. Maybe something in that is breaking for you.

I'm not sure if the video represents what's going on perfectly, but it appears like maybe it's reading old data from an improperly cleared framebuffer or something?

I swear, the guy must be a genius.

Out of curiosity, what are the WebGL bugs you ran into?

I had a very similar pattern happen a year or so ago on one of my bank debit cards. The difference in my case was that they made one fraudulent charge on the card beforehand to lend authenticity to the "we're the fraud team" claim. They knew the card number, and the details about the charge (presumably because they were the ones who made the charge). Then they tried to reset the password for my online banking login and asked me to read the security code I received via SMS to confirm my identity. Luckily the code sent to me was clearly labeled as a password reset code (though not with the "we won't ask for this code over the phone" line), so I froze the card and went down to my bank to talk about it. Apparently it had happened to a lot of my bank's members, and I was one of the few to not fall for it.

"Discrete TPM" means you have a daughter board that you plug in to a physical TPM port on the motherboard (check your motherboard manual for where it is, and which kind is compatible). If that device is physically not actually there, then that BIOS option does nothing for you.

You should check and see if the "Firmware TPM"/"fTPM" option is available, because that one will work without the physical add-in card.

Whoah, that's news to me.

I used PostgreSQL fairly recently (a year or so ago?) and ended up abandoning it after I was forced to do the export/import dance through a few version upgrades.

When did that requirement go away?

Gallium, Indium, and Tin, I believe.