4 ms·
> 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 S
by Shank 2y ago
> 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-emulators-ios-rejection https://www.theverge.com/2024/6/24/24185066/apple-pc-dos-emu...
- infotainment 2y agoLet'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.
- lxgr 2y ago> 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 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 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 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.
- p_l 2y agoApple 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.
- akmarinov 2y agoMeanwhile, every RN app uses CodePush to dynamically update its code
- cageface 2y agoI 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.
- idle_zealot 2y agoNotarization 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.
- cageface 2y agoThe requirement for a hardened runtime certainly supports this point of view.
- rekoil 2y agoApp 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.
- Someone 2y ago> 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.
- TillE 2y ago> 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.
- phone8675309 2y agoRight? By that logic, why have laws against murder?
- hulitu 2y agoBoeing whistleblowers ? /s