Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Apple bremst Retro-Spiel-Emulatoren – aus Willkür oder Sicherheitsbedenken?

Kürzlich entschloss sich Apple zu einer Kehrtwende und gab Emulationen historischer Spielekonsolen im iOS sowie iPadOS App Store frei. In direkter Folge wuchsen die Angebote – und zugleich entstanden Begehrlichkeiten: Um anspruchsvollere Spiele zu emulieren, wünschten sich Entwickler Zugriff auf Just-in-Time-Kompilierung. Die Entwickler des plattformübergreifenden Emulators Dolphin führten jüngst vor, welchen Unterschied dies macht – N64-Spiele liefen tadellos mit aktivierter JIT, ohne diese verwandelten sie sich in eine (unspielbare) Diashow. Auf eigenen Geräten düren Entwickler JIT nutzen, Apple verweigere Emulatoren jedoch das JIT-Privileg für App Stores (und alternative App-Marktplätze). Dass dies nicht unbedingt ein Versuch ist, die Konkurrenz kleinzuhalten, sondern auch auf Sicherheitsbedenken zurückzuführen ist, zeigt eine zusätzliche Einschränkung: Im Blockierungsmodus deaktiviert Apple JIT – auch für den eigenen Browser.


Mac-Blogger John Gruber zeigt auf, wie streng Apple den Zugriff auf JIT-Kompilierung reglementiere. Bis vor Kurzem durfte nur Safari (und deren Engine WebKit) JIT verwenden. Damit nicht genug: Um besonders exponierte Personen, beispielsweise Journalisten oder Menschenrechtler, vor gezielten Angriffen zu schützen, deaktiviere Apple JIT im hauseigenen Browser, sobald der Blockierungsmodus aktiv ist.

Sicherheit vor Geschwindigkeit
Den extrastark abgesicherten Modus empfiehlt Apple nur in absoluten Ausnahmefällen – er resultiert im Verlust einiger Komfort-Features. Vorschauen von per iMessage zugesandten Links verschwindet, Button-Icons auf vielen Websites werden durch leere Kästen ersetzt. Zudem browst es sich wie mit angezogener Handbremse: iPhones wie iPads zeigen beim Speedometer-Test eine halbierte Punktzahl. Beim Surfen schlägt die Limitierung glücklicherweise nicht allzu sehr ins Gewicht, da zusätzliche Faktoren wie beispielsweise Datenrate eine ebenso große Rolle spielen wie JavaScript-Leistung.

Wer den Blockierungsmodus einschaltet, verringert damit deutlich die Verarbeitungsgeschwindigkeit des Safari-Browsers.

Sollten Emulatoren JIT nutzen dürfen?
Gruber argumentiert, dass Apple hier den richtigen Weg gehe: Konsolenemulationen sind dafür gedacht, Softwaretitel auszuführen, die nicht dem App Store entstammen. Dabei kommen nicht immer nur legitime Homebrew-Titel zur Anwendung; einige Anwender beziehen ihre Images aus nichtoffiziellen Quellen. Über ein kostenlos in Tauschbörsen offeriertes Spiel könnten böswillige Entwickler auf diese Weise Code auf iPhones und iPads mit hoher Leistung zum Laufen bringen, Daten abgreifen und das gesamte System kompromittieren. Deshalb sei eine unregulierte Vergabe des JIT-Privilegs an Entwickler für Emulatoren ein zu großes Risiko für die gesamte iOS- und iPadOS-Plattform. Apple habe mit BrowserEngineKit ein für alternative Browser prädestiniertes Framework entwickelt und knüpfe deren Verwendung an bestimmte sicherheitsbezogene Bedingungen. Das sei der korrekte Weg, um Systemsicherheit zu gewährleisten – und gleichzeitig alternative Browser-Engines zuzulassen.

Kommentare

Zacks
Zacks27.06.24 14:12
Willkür. Wie auch die ganzen letzten Jahre.
Die Leute sollen ja auch Apps kaufen oder das dusselige Apple Arcade abonnieren und keine Klassiker für kostenlos emulieren
Ware wa messiah nari!
-6
ND27.06.24 16:10
Ich weiß nicht, wovon du sprichst. Ich habe einen Emulator auf dem Mac, der gut funktioniert.

Mir ist Sicherheit wichtiger, als ein paar olle, alte Spiele zu zocken.
-4
Dunnikin27.06.24 16:17
ND
Ich weiß nicht, wovon du sprichst. Ich habe einen Emulator auf dem Mac, der gut funktioniert.

Mir ist Sicherheit wichtiger, als ein paar olle, alte Spiele zu zocken.

Ähm … Artikel gelesen? Wohl nicht. Es geht um mobile OS, nicht um den Mac.
+5
Unwindprotect27.06.24 16:18
Zacks
Willkür. Wie auch die ganzen letzten Jahre.
Die Leute sollen ja auch Apps kaufen oder das dusselige Apple Arcade abonnieren und keine Klassiker für kostenlos emulieren

Die Sicherheitsbedenken die in der Doku zu BrowserEngineKit beschrieben werden sind alles andere als „Willkür“. Das Problem ist hier, das derartige Apps Daten aus beliebigen Quellen entgegen nehmen, daraus dann selbst Maschinencode erzeugen, der dann auch im selben Prozess ausgeführt werden darf. Bislang wird das in iOS verhindert um Angriffe zu verhindern.

Mit BrowserEngineKit ist es möglich für den Anwendungsfall von JavaScript JIT Compilern so etwas zu verwirklichen indem diese JS engines vom Rest isoliert werden um so die Angriffsfläche zu reduzieren.

Das jetzt einfach für beliebige Apps zu erlauben, nur weil der Anwendungsfall „Emulator“ für ein paar Freaks interessant ist um rauskopierte ROMs aus zwielichtigen Seiten auf dem Handy auszuführen ist schon etwas über das man nachdenken sollte
+6
Dunnikin27.06.24 16:25
Unwindprotect
Zacks
Willkür. Wie auch die ganzen letzten Jahre.
Die Leute sollen ja auch Apps kaufen oder das dusselige Apple Arcade abonnieren und keine Klassiker für kostenlos emulieren

Die Sicherheitsbedenken die in der Doku zu BrowserEngineKit beschrieben werden sind alles andere als „Willkür“. Das Problem ist hier, das derartige Apps Daten aus beliebigen Quellen entgegen nehmen, daraus dann selbst Maschinencode erzeugen, der dann auch im selben Prozess ausgeführt werden darf. Bislang wird das in iOS verhindert um Angriffe zu verhindern.

Mit BrowserEngineKit ist es möglich für den Anwendungsfall von JavaScript JIT Compilern so etwas zu verwirklichen indem diese JS engines vom Rest isoliert werden um so die Angriffsfläche zu reduzieren.

Das jetzt einfach für beliebige Apps zu erlauben, nur weil der Anwendungsfall „Emulator“ für ein paar Freaks interessant ist um rauskopierte ROMs aus zwielichtigen Seiten auf dem Handy auszuführen ist schon etwas über das man nachdenken sollte

Das ließe sich lösen, indem die Apps Daten eben nicht aus irgendwelchen Quellen beziehen, sondern „fertige“ die Daten nur lokal beziehen und nicht Code selbst erzeugen können. Also das Prinzip wie in VLC.
-6
Unwindprotect27.06.24 18:43
Dunnikin
Das ließe sich lösen, indem die Apps Daten eben nicht aus irgendwelchen Quellen beziehen, sondern „fertige“ die Daten nur lokal beziehen und nicht Code selbst erzeugen können. Also das Prinzip wie in VLC.

Dann brauchst Du keinen JIT und kannst das/die Game(s) einfach vorher bauen.
+1
GHS
GHS27.06.24 19:00
Ich spiele, nach sehr vielen Jahren Pause wieder. Auf den MacBook Air Stray und seit kurzem auch wieder Kondole. Meine ersten Games waren von Lucas Arts und Sierra Online (1000 Tode 😂)

Auf dem iPad Pro spiele ich eher olle Wimmelgames…werde wohl langsam alt 👴
Seht die Welt aus anderen Augen.
+1
Fischmuetze28.06.24 08:24
Vorgeschobenen Argumente ... Auf jeder anderen Platform, inkl. aller Desktopsysteme gibt es kein derartiges "Betreutes Wohnen". Einen essentiellen Sicherheitsgewinn gibt es dadurch nicht... jedenfalls ist Apple den Beweis dafür schuldig geblieben
0
chicken28.06.24 08:36
Also ich bin der Meinung, sie sollten es dem User überlassen.
Will dieser unbedingt auf Emulatoren zurückgreifen und nutzt dann (möglicherweise) Quellen mit dubioser Herkunft - wem schadet es?

Dem AppStore? Nein
Anderen Kunden die diesen Emulator nicht nutzen ? Nein

Also, soll sich doch jeder auf sein iOS Device laden was er will - wer dann später ein Problem hat, muss halt mit der Konsequenz seines eigenen Handels leben!
Ist das so schwer oder übersehe ich da etwas?
+2
Robby55528.06.24 15:56
Was geht es Apple an woher die User ihre Spiele her kriegen? Auf dem Mac kann man auch Emulatoren installieren und damit tun was man will. Auf iPadOS ist es reine Willkür, das Argument mit der Sicherheit ist nur vorgeschoben.
0
AppleUser2013
AppleUser201329.06.24 00:44
Da sieht man halt absolut und definitiv den Unterschied zwischen MacOS und IOS/IPadOS...
MacOS ist frei, Ipad OS und Ios sind es nun mal nicht...
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.