Hacker News Reader

Comment by dagmx | Hacker News Reader

All the things you listed aren’t blocked by the App Store.

They’re system level restrictions based on the security model (whether or not one agrees with them)

Today you can already find terminals and IDEs in the App Store beholden to those restrictions.

The DMA also prohibits companies from placing restrictions on third-party apps that don't apply to their own apps. So if any first-party Apple apps can ignore these "security restrictions" then Apple may have some compliance issues that force them to remove the restrictions.

But the DMA also requires (not just allows) platform owners to maintain the security of their platform. Many of the security model restrictions for iOS that app developers bump into are unlikely to be lifted by Apple.

Most of the places Apple has given themselves special powers is mostly a shortcut to avoid the hard work of a publicly accessible API and entitlements. Not always, sometimes it really is them favouring themselves, but I'd say that's the exception rather than a rule. I'm guessing Apple will mostly do the legwork to create entitlements and APIs and transition the Apple apps rather than actually remove the restriction.

This will result in some types of apps that are currently not allowed being possible, but I think it's going to be a lot fewer use cases than people think. For example, I don't see side loaded NES emulators being allowed to have a JIT.

> For example, I don't see side loaded NES emulators being allowed to have a JIT.

Why not? If third-party browsers are allowed to have a JIT, why couldn't an emulator?

Apple has a slam dunk case to place a ton of barriers on browser vendors being allowed to JIT code due to the risk to the rest of the platform and the user's data.

Little emulators for NES and Sega Genesis are not going to meet those barriers and Apple will have a pretty easy time excluding them under the security provision.

Dev environments like VS Code will be more interesting. I suspect Apple will choose to build a VM layer to execute complied code inside an even deeper sandbox rather than allowing execution directly inside the iOS layer, thereby severely limiting what a binary complied on device is able to interact with. This would almost certainly be hidden behind an entitlement that Apple will be try to be allowed to gatekeep under the DMA requirement to maintain platform security.

Samsung already offers virtualizations and containerization via KNOX for you to run apps you don't fully trust safely without disk and shared memory access, on their midrange phones.

Surely Apple being wealthier and selling higher priced phones, with even more powerful SoCs can definitely offer similar security functionality for non-IOS appstores. The reason they aren't is they want to push the security boogieman scaremongering to defend their monopoly.

By every measure (go read and told up the CVEs), Chrome has a better security track record than Safari. That means by not allowing users to use Chrome (or a Chromium variant), Apple is forcing users to use a less secure browser and a less secure JavaScript and less secure JIT.

fwiw, I submitted a DMA interoperability request for JIT access on non-browser apps.

Apple denied it on the grounds that it doesn't fall under Article 6(7) for "multiple reasons". One such reason they gave is that JIT is only used for web browsers on iOS.

Sounds like all you need to do is write a web browser that just so happens to include an emulator...

By what possible reasoning would the DMA forbid things in the phone that have always been standard on all major computer operating systems as well as with Android? It’s pretty clear the DMA does not intend for such specious security arguments to allow Apple to avoid the obligation to open up their platform in th EU.

There is a provision in the act that gatekeepers can still restrict access if it that required to maintain the platform's security.

If Apple will continue blocking on device compilation and other app functionality, they may well have their interpretation of what is and isn't a security measure tested in court. If there are competent lawyers involved, it will likely come down to the question of which rules are technically meaningful vs. present only to stifle competition.

But it obviously isn’t required to maintain security of the platform. Apple manages to run MacOS in a more open fashion. Is the argument that MacOS is illegally insecure or something? If the enforcers of the DMA allow a company to simply build their security policy in a way to avoid the rules enforcing the opening of the platform, then what’s the point of the DMA in the first place? Honestly I don’t think Apple will talk their way out of this. EU regulators seem to be much less forgiving of such shenanigans. It’s obvious the point of the DMA is for Apple to open up their platform.

That said only time we’ll tell how this plays out.

I tend to agree with you. But things that seem obvious to us techies may not be that obvious to laymen. Also, legal interpetations of a situation may be abstracted a lot from the underlying facts. So if this goes to court, the likelihood of a very bizarre ruling is not 0.

You can read the DMA yourself. In fact, you should read the DMA yourself and not rely on what EC commissioners say on their social media accounts. The EU court of justice can and will throw their rulings and fines out the window when (not if) they overstep their authority to score popularity points.

If Apple were to create an OS from scratch tomorrow, and that OS was subject to the DMA on day 1, they probably would not be allowed to do many of the things that Apple does in iOS. But the DMA can never apply to an OS on day 1 and the DMA cannot force Apple to roll back many of their security features once an OS becomes subject to the DMA. It’s all in the text of the DMA. Read it.

What is it about JIT that makes it more risky than running non-JIT code?

This is all technically true, but an IDE that cannot compile and run the code on the local device is missing something. The prohibition on JIT or otherwise compiling on device and running the result is a big blocker for a lot of true native dev experiences. I say this as someone who really mostly likes the App Store, but who would really like to be able to compile some code or run a VM with decent efficiency.

Efficient VMs on iPhone would be great. I experimented with sideloading Jitterbug (1) and using it to launch qemu, but the process currently requires a second device or setting up a VPN - in practice it was annoying.

I just want/need a Linux environment; coming from my laptop, I really miss rsync… FTP/SMB over VPN work but rsync is usually faster!

Fingers crossed that easily sideloading apps becomes a thing here in the US.

1: https://github.com/osy/Jitterbug

Can ish not run rsync?

Sure, but does side-loading or alternate app stores of notorized apps mean that you'll be able to ship arbitrary JIT-enabled apps and apps which allow arbitrary execution of downloaded native binaries?

Yes. That’s the point. Edit: that’s too glib. The restrictions currently aren’t technical, they’re enforced by what is and isn’t allowed in the App Store. It’s perfectly possible to build the software on iOS today, you just can’t distribute it within apple’s rules

Not a JIT, iirc: from what I understand, without a specific JIT entitlement only Apple can give an app, it’s impossible to mark a memory page writable, write code to it and then mark it executable and run the code. This is a core security feature of the operating system.

That’s correct AFAIK, but assumes a specific kind of JIT. It’s entirely possible for a JIT compiler to produce shared libraries (dyld files in this case) which are then loaded into the process with dlopen. It’s slower to produce a compiled function or module this way, but we actually do it in practice to allow use of compilers that aren’t traditional JIT compilers or to work around similar selinux policies. This means something like luajit wouldn’t work out of the box, but a single-pass JIT binary translation like Rosetta would work fine. Same thing for a JIT like that used in Julia IIRC.

Reply on news.ycombinator.com