←back to thread

Apple vs the Law

(formularsumo.co.uk)
377 points tempodox | 2 comments | 11 Jul 25 06:49 UTC | HN request time: 0s | source
Show context
grishka ◴[11 Jul 25 07:28 UTC] No.44529279[source]▶
> "...unfortunately, it's impossible to do all the complex engineering to comply with the Commission's current interpretation of the DMA..."

There's nothing complex and impossible about removing some "if" statements responsible for code signature enforcement.

replies(9): >>44529310 #>>44529322 #>>44529363 #>>44529431 #>>44529446 #>>44529695 #>>44530078 #>>44531016 #>>44531269 #
interpol_p ◴[11 Jul 25 07:40 UTC] No.44529363[source]▶
It’s extremely complex. I’m not debating whether they should comply - they should. But it’s gonna cost them years of engineering effort, and maintenance far into the future. See, for example, BrowserEngineKit

https://developer.apple.com/documentation/browserenginekit

They needed to engineer, maintain, document and support a whole class of APIs so that third parties can create their own competitive browser engines (that offer JIT, etc) while still maintaining iOS sandbox security. There are going to be hundreds of frameworks, thousands of APIs, that will need to come to ensure compliance with the DMA

replies(2): >>44529396 #>>44529401 #
EMIRELADERO ◴[11 Jul 25 07:48 UTC] No.44529401[source]▶
Somehow, Android manages to do it. Not only for browsers; all apps have JIT access without any entitlement/review needed.

It doesn't seem like the average Android user is worse-off because of that, security-wise.

replies(3): >>44529515 #>>44529733 #>>44533177 #
1. grishka ◴[11 Jul 25 08:05 UTC] No.44529515[source]▶
And Android apps can be installed from apk files without any Google involvement whatsoever. All apks are self-signed anyway and signing identity only comes into play for updates, not initial installation. As in, when you first install an app, it doesn't matter who signed it, but installing an update over an existing app requires the new apk to be signed with the same certificate as the initial one. This is to protect the potentially sensitive data in app's private storage (under /data/data).

But iOS requires that everything be signed by Apple in one form or another. Even debug builds of your own apps you run on your own device from Xcode. IMO, it is absolutely unacceptable to market your devices as general-purpose ones, make the SDK public, but still be an intermediary in app distribution for no good reason whatsoever. I'm surprised the EU is so seemingly patient with Apple's clearly contemptuous conduct.

replies(1): >>44533254 #
2. interpol_p ◴[11 Jul 25 15:27 UTC] No.44533254[source]▶
Google engineered and maintains the system that allows you to install APK files. This is my point. The fact that they have developed a security model around APK updates is exactly what I'm talking about.

If Apple wants to offer something similar, now, they are going to have a lot of work cut out for them.

You're not thinking this through, it's not a magic button Apple presses. They are going to have to develop a ton of frameworks just to get something like installable APKs.

Apple allows developers to use iCloud and Maps for free. Presumably because you distribute through the App Store. So if they allow for side-loading they're going to have to lock down and split their App Store "services" into a separate framework — hey, sounds familiar? Just like Google Play services.

Separating out all of Apple's authentication layers, paid and cloud services, and ensuring apps can be cleanly distributed without dependencies on those things it not a trivial engineering exercise.

I'm not trying to imply that Apple should not comply with the DMA. I believe they should. I also believe that it would be a seriously complicated thing to extract their App Store services from their developer APIs in such a way that people could develop against a baseline SDK sans Apple services.