Hacker News Reader

Comment by theluketaylor | Hacker News Reader

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.

View on HN

> 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.

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.

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.

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

Reply on news.ycombinator.com