Hacker News Reader

Comment by Shank | Hacker News Reader

> We need a DMA over here yesterday.

I understand why you would believe this, but Apple currently refuses to notarize UTM for distribution outside of the App Store via Notarization under rule 2.5.2:

> UTM also noted that Apple is barring UTM SE from being notarized for third-party app stores because the app apparently violated guideline 2.5.2. That rule states that apps have to be self-contained and can’t execute code “which introduces or changes features or functionality of the app, including other apps.” [0]

While the DMA may eventually force Apple to slide on this rule, currently it doesn't actually solve the problem at-hand.

[0]: https://www.theverge.com/2024/6/24/24185066/apple-pc-dos-emu...

View on HN

> While the DMA may eventually force Apple to slide on this rule, currently it doesn't actually solve the problem at-hand.

People keep saying stuff like this about the DMA and it's very confusing to me. Of course Apple can choose to break the law, but there are consequences for that. It doesn't mean the law is ineffective just because investigation and enforcement is not instantaneous.

Right?

By that logic, why have laws against murder?

Boeing whistleblowers ? /s

> apps have to be self-contained and can’t execute code “which introduces or changes features or functionality of the app, including other apps.”

Meanwhile, on the very same app store:

iSH – runs unmodified x86 Linux binaries and even supports custom APK repos: https://apps.apple.com/us/app/ish-shell/id1436902243

a-Shell – runs WASI binaries (via Apple's native out-of-process runtime, so it even gets to JIT, I believe!) and comes with a C compiler, as well as Python: https://apps.apple.com/us/app/a-shell/id1473805438

LibTerm – compiles and runs arbitrary C via lldb: https://apps.apple.com/us/app/libterm/id1380911705

But yeah, sure these are all somehow self-contained in a way that a DOS emulator can't possibly be in a way only App Store reviewers are enlightened enough to grasp.

Apple has been well known to be absolutely obtuse, random, and not reliable when it comes to approvals for over 12 years now[1], at least unless you're a big company and can hound someone in upper management about it.

It's a good reason why, for a lot of people, claims about Apple walled garden being such a privacy and security boon fall flat[2].

For all purposes, it's as capricious as other companies inscrutable "AI" systems.

[1] Back in 2011, when I tried my hand at the startup roulette, I remember meeting companies which due to bad experience decided that Apple market is not worth possibility of going bankrupt because approvals might suddenly get denied so late in the process to kill the project

[2] I remember how, before MS started submitting their own applications to AppStore/MAS, searching for certain microsoft products like a naive user got you a ton of scams that might be threading the needle on Apple rules - but not on intent.

Meanwhile, every RN app uses CodePush to dynamically update its code

What is a RN app?

React native. the code of the app is in javascript, and so updates can be downloaded dynamically by the app itself, without the need to submit another version to the app store

Let's hope it forces their hand. Either way, it shows that there is room for improvement to the DMA language to prohibit that type of behavior explicitly, which other countries could address in their DMA versions.

I could sort of see the justification for requiring notarization giving Apple a kill switch to shutdown malware. But if it's just turning into another kind of app review then we can't really say the Mac is still an open platform.

Notarization is not a reasonable implemetation of a malware kill switch. All you'd need for that is an Apple-published list of known-bad app ids that the OS could check itself against periodically. No, notarization is a control mechanism to impede the creation and distribution of any non-Apple-approved apps.

App IDs don't really work for this purpose if Apple aren't in control of generating them, nothing is stopping a malware vendor from literally never reusing app IDs. Notarization is a reasonable implementation, and it can even require some form of developer identification, it just can't be very deep identification, an e-mail address is enough (along with IP and other metadata gathered during the process). That way they can disable all apps signed by one developer, and can more quickly react to malicious actors, without it becoming a problem for normal users.

> nothing is stopping a malware vendor from literally never reusing app IDs.

Or form using the ID of another vendor.

> and it can even require some form of developer identification, it just can't be very deep identification, an e-mail address is enough (along with IP and other metadata gathered during the process).

I expect the typical malware writer will easily find a way to have a unique “e-mail address (along with IP and other metadata gathered during the process)”.

Because of that, “That way they can disable all apps signed by one developer” will not be possible.

Yes, but all attempts at circumventing the system will give Apple more information about their behaviour. If 1000 different users are requesting to sign the same (or only slightly differing) IPA within a short period of time, from different IPs and different emails, it's a good indicator that something fishy is going on.

The requirement for a hardened runtime certainly supports this point of view.

Reply on news.ycombinator.com