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

Browser-Vielfalt unter iOS gefordert – #AppleBrowserBan

Wer sich im App Store nach anderen Browsern umsieht, wird durchaus fündig. Neben Safari stehen auch Chrome, Edge und weitere Angebote zur Verfügung. Was normalen Nutzern allerdings meist gar nicht bewusst sein dürfte: Dabei handelt es sich um weitaus weniger eigenständige Browser, als man eigentlich denken könnte. Apple schreibt nämlich vor, dass ausschließlich WebKit-basierte Browser erlaubt sind. Somit müssen alle Anbieter dieselbe Engine verwenden – was aus den alternativen Angeboten oft nicht mehr als ein "Safari mit anderem Skin" macht. Die noch sehr junge Gruppe namens Open Web Advocacy (OWA) will nun genügend Stimmen sammeln, um Apple von einem Kurswechsel zu überzeugen.


Forderung: Apple muss endlich Wettbewerb zulassen
Der Gründungszirkel besagter Gruppe setzt sich aus englischen Entwicklern zusammen, die für eine offenere Web-Landschaft eintreten wollen. Gerade Apples Vorgaben bezüglich der Browser-Engine stehe aber diesem Ziel vollständig entgegen. Wenn eine Plattform mit mehr als einer Milliarde aktiver Nutzer Browser-Wettbewerb verhindere, müsse es Widerstand geben. Natürlich können iOS-Browser mehr tun, als Safari-Features nur durchzureichen, funktionell unterscheiden sich die Browser durchaus. Allerdings sind den Möglichkeiten deutliche Grenzen gesetzt – Shortcuts auf dem Homescreen abzulegen ist beispielsweise unterbunden. In der Vergangenheit war es auch so, dass Drittanbieter auf eine langsamere JavsScript-Engine als Safari setzen mussten, womit sich Apple einen Plattformvorteil verschaffte.

Kritik an Apples Web-Politik wird immer lauter
Die Gruppe reiht sich damit in den größer werdenden Kreis der Kritiker ein, die Safari und WebKit als den "neuen Internet Explorer" bezeichnen. Wie es von der OWA heißt, trete das Safari/WebKit-Team seit zehn Jahren auf der Stelle und trage keine Innovationen mehr bei. Aktiv habe die Gruppe dafür gesorgt, Web-Apps sowie modernere Web-Anwendungen zu behindern.

Sollen die Wettbewerbshüter eingreifen
Sollte Apple sich weiterhin weigern, eigenständige Browser zu erlauben, müsse man in einem nächsten Schritt die Wettbewerbsbehörden einschalten. Auch wenn die Sicherung der Safari-Marktanteile für Apple ein wichtiger Faktor sein dürfte, immerhin verdient das Unternehmen mit Google-Anfragen via Safari Milliarden, gibt es handfestere Gründe für die Verweigerung. Ein Argument ist beispielsweise, eine so sicherheitskritische Schnittstelle zur Außenwelt kontrollieren zu können. In der Ausführung von Web-Apps mit beliebigem Funktionsumfang, möglich durch eigenständige Browser, sieht das Unternehmen gleich in mehrfacher Hinsicht Probleme. Im Falle von Sicherheitslücken in WebKit verspricht sich Apple zudem, sämtliche Browser gleichzeitig patchen zu können. Allerdings ist Apple nicht gerade dafür bekannt, besonders schnell auf Sicherheitslücken zu reagieren – vor allem, weil es im Falle des Browsers sogar noch eines kompletten Systemupdates bedarf.

Wettbewerbshüter zögerlich
Bislang gibt es keinen ernstzunehmenden Druck von Wettbewerbshütern, Apple zu mehr Browserfreiheit zu zwingen. In den Diskussionen der letzten beiden Jahre steht der App Store im Mittelpunkt, weniger hingegen die Browserfrage. Von Wettbewerbshütern in Großbritannien war kürzlich "Sorge" bezüglich des Einflusses von Apple und Google auf die gesamte Mobilfunkwelt zu hören, wenngleich man die "Browser-Monokultur" nicht unbedingt Apple in die Schuhe schieben will. Mit Chrome, Edge und Opera setzen drei einflussreiche Anbieter auf Chromium und bringen es auf 80 Prozent Marktanteil – ob es daher für mehr Wettbewerb sorgt, wenn Chromium auch noch unter iOS zum Einsatz kommt, ist daher mehr als fraglich.

Kommentare

deus-ex02.03.22 09:59
Wenn es dann eine Lücke in der Gecko Engine oder Chrome Engine gibt die zur Sicherheitslücke für iOS wird, dann heißt es "iPhone unsicher". Und kein Sau hat einen Überblick welche Apps diese Engine dann noch benutzen und gefixt werden müssen.

Nein Danke. WebKit ist doch vollkommen ok.
+4
Metty
Metty02.03.22 10:13
Die Kritik ist nicht unberechtigt, Die Webkit Engine hängt bei der Implementierung der Web Standards hinterher und blockiert damit die Weiterentwicklung des Web. Alle Entwickler müssen sich auf die Features beschränken, die gerade noch auf iPhone und iPad laufen. Auf dem Mac habe ich die Auswahl. Unter iOS nicht und genau das ist der marktbeherrschende Missbrauch.
Wenn es dann eine Lücke in der Gecko Engine oder Chrome Engine gibt die zur Sicherheitslücke für iOS wird ...

Sicherheitslücken können in jeder App auftauchen. Sicherheit kann also nicht das Kriterium für den Ausschluss einer anderen Web Engine sein. Dafür gibt es das Sandboxing.

Die Behauptung, dass Safari der neue Internet Expolrer ist kann ich nur bestätigen. Am Kleingeld kann es bei der Entwicklung ja nun wirklich nicht mageln.
+9
wicki
wicki02.03.22 10:31
Metty
Die Kritik ist nicht unberechtigt, Die Webkit Engine hängt bei der Implementierung der Web Standards hinterher und blockiert damit die Weiterentwicklung des Web.

Das sehe ich anders. Cui bono?

Apple hinkt bei der Implementierung von Webstandards nicht hinterher – es verfolgt andere Ziele, als Google.

Zwei Dinge:
1. ich nehme Apple seine Überlegungen bzgl. Privacy zum großen Teil ab. Google möchte den total transparenten Nutzer (um Werbung verkaufen zu können), Apple nicht (weil sie mit Hardware ihr Geld verdienen). Daher implementiert Apple in der Tat solche Web-Features in Webkit nicht, die nur der noch besseren Durchleuchtung der Nutzer dienen. Das mag den einen oder anderen Entwickler von Trackingsoftware stören – mich hat es noch nie gestört.

2. Google (und in gewissem Maße auch MS, dass sich immer mehr zur Server-Company entwickelt) verfolgt das Ziel, das Betriebssystem und seine nativen Oberflächen vollständig durch Croosplattform-Web-Apps zu ersetzen. Auch daran hat Apple naturgemäß kein Interesse. Es besitzt ja – im Vergleich zu Windows, Linux-Dekstop und Android ja schon die besten und benutzerfreundlichsten Oberflächen – für Mobile und Desktop. Warum also den Browser zur Ersatz-Desktop aufbohren? Dabei kommen nur so Crapp-Apps wie Skype (neu), Slack oder ähnlicher Elektron-basierter Mist bei raus.
+9
Metty
Metty02.03.22 10:59
wicki
Das sehe ich anders. Cui bono?

Ich nehme Euch die negativen Bewertungen nicht übel. Für den Benutzer sind diese technischen Aspekte nicht offensichtlich und Apple kaschiert sie mit seinem Marketing ganz geschickt. Wer an den Details interessiert ist, den könnte dieser Artikel interessieren.

https://httptoolkit.tech/blog/safari-is-killing-the-web/

Als Webentwickler bin ich jedoch von Apple enttäuscht.
+8
TiBooX
TiBooX02.03.22 11:44
Das Problem ist nicht der Browser

Das Problem sind die Myriaden von superschlechten (bezüglich Sicherheit) Code-Bibliotheken zweifelhafter Herkunft, die so gern von den ich-kann-nix-aber-ich-'programmiere'-alles-was-mobil-ist-und-nicht-bei-3-auf-den-Bäumen verwendet aber weder evaluiert noch gepflegt werden.

Wieso?
Man sehe sich nur mal an wie unkritisch und in wahllosen Ausmass Killer-Bibliotheken von bestimmen App-Entwicklern eingebunden werden.

Alleine das "Über diese App" (wenn es denn eins gibt! das hat Apple versaut) listet 30-50 oder mehr (unnötige) Bibliotheken auf, die dann auch noch mit zig weiteren Abhängigkeiten pro Library daherkommen.
Und zu allen Überfluss macht der ganze Sauhaufen nicht mehr als was das Betriebssystem bereits seit Jahren on-Board teils sogar Harware-optimiert anbietet! (Teams VideoCodecs!?)

Da brauchen wir nich mehr lange auf den nächsten Super-Gau auf MobilGeräten - a la Log4j - zu warten.
Nur dass Mobilgeräte bereits eine so wichtige technische/gesellschaftliche Rolle für uns spielen. "That's not going to be pretty"
Malware die Notrufe Systeme oder (mobile) Anlagensteuerung, Navigation, Avionik, Flottenmanagement lahmlegt sind da noch die kleinsten Dinge. (Ich war an einer iPad.App für Airlines massgeblich beteiligt)

Wer's nicht glaubt, einfach mal wahllos ein paar 1-trick-pony-apps runterladen und beeindruckt herausfinden welchen (teils gefährlichen) Schott die mit sich rumschleppen, den sie eigentlich garnicht verwenden(sollten?).
Und ich meine nicht mal den ganzen Spanner- und Tracking-Ballast 🤑.
Kaum ein seriöser Entwickler (mich eingeschlossen) überblickt heute noch die ganzen Bugs und (unnötigen) Abhängigkeiten in diesen Bibliotheken. Die wenigsten haben die Möglichkeit und die Zeit diese zu evaluieren (weil sie sich dank 'agile Dev' alle paar "Minuten" ändern.
Ich würde mich schämen solch großteils halbgaren alpha-Scheiß zu 'releasen'.
Es gibt gute Gründe vitale Bibliotheken wie WebKit vom Betriebssystemhersteller pf
People who are really serious about software should make their own hardware [A. Kay]
+8
TiBooX
TiBooX02.03.22 12:12
Metty

Als Entwickler der seit Apple ][ auf Apple Geräten entwickelt bin ich vollkommen vom der 'Qualität' der meisten WebEntwickler enttäuscht!

Wer gegen den mehrfachen Rat und reichlich guten Beispielen wie/warum man es richtig macht immer noch Burger-Menüs in Apps verwendet hat von mir kein Mitleid verdient.

Auch diese overdone React-Scheisse, die meist zum ewigen hin- und herflippen des Inhalts sorgt geht mir gewaltig auf den Zeiger.

InsideMac I-III (1984) "Give the USER as much control as possible!"
Der feuchte Traum _einen_ Code für aller Geräte/Bildschirmauflösungen/Browser/Betriebssysteme zu schreiben hat noch nie! funktioniert und belästigt in der Regel nur ALLE anderen Benutzer mit halbherzigen Kompromissen.

I-70 Do's and Dont's of a Friendly User Interface (1984...)
Don't:
* Take an old-fashioned prompt-based application originally developed for another machine and pass it off as a Macintosh application.

Heisst heute (2010...):
Don't:
* Take an old-fashioned HTML-based WebPage originally developed for another Browser and pass it off as a Mobile App.

And guten Grundprinzipien änder sich so schnell nichts.
People who are really serious about software should make their own hardware [A. Kay]
+2
OMA
OMA02.03.22 12:38
Wird Zeit, dass Apple hier aufmacht. Safari kann so einiges nicht, was das moderne Web hergibt und das ist eine Behinderung von Entwicklung.

"… ob es daher für mehr Wettbewerb sorgt, wenn Chromium auch noch unter iOS zum Einsatz kommt, ist daher mehr als fraglich.…" Ich denke es kommt zu mehr Wettbewerb, da sich Chromium-basierte Browser im Funktionsumfang deutlich unterscheiden. Ich nutze derweil Brave, wenn es um Chromium geht, würde aber auch gern Vivaldi nutzen können. Firefox hat auch seine Vorteile, sowie eine eigene WebEngine.
0
heubergen02.03.22 14:32
Damit uns diese Geschwür von Chromium auch noch auf dem iPhone "beglückt"? Nein, danke. Es ist ganz gut wenn Google (und alle anderen) gezwungen sind ausserhalb ihres Lieblings noch einen zweiten Browser zu unterstützen.

Wir brauchen auf dem iPhone keine PWA die eine Tonne JavaScript nachladen und nicht wirklich offline funktionieren. Wir wollen nativ geschriebene Apps in Swift die nicht 100MB gross sind weil 12 Tracking SDK eingebunden werden.

OMA
Ich denke es kommt zu mehr Wettbewerb, da sich Chromium-basierte Browser im Funktionsumfang deutlich unterscheiden.
Engine/Browser-Unterbau ist im Krieg der König. Es braucht mehrere davon.
+2
Terendir04.03.22 00:11
Naja, ich würde die Forderung vielleicht unterstützen, wenn "mehr Browser-Vielfalt" nicht eine Alibi-Floskel wäre, die auf "noch mehr Macht für Chromium" hinauslaufen würde.

Der Safari / WebKit ist die letzte, zahlenmäßig relevante Alternative zum Chromium-Imperium. Und ja, dass man auf iOS nix anderes als WebKit einsetzen kann, hilft dabei, dass der Safari im Sattel bleibt.

Andererseits muss sich Apple aber auch langsam mal sputen, und mit Webkit bezüglich Funktionen und Optimierung nachziehen. Daher stehe ich hier etwas zwischen den Stühlen. Der Safari muss einiges aufholen, aber selbst im aktuellen Zustand ziehe ich den Safari vor. Ich hab einfach massive Bedenken gegen ein Browser-Monopol (noch dazu das größte bisher), das dann auch noch ausgerechnet von einer der größten Datenkraken stammt.

Bei allen Mängeln die der Safari hat, empfinde ich das langfristige Risiko eines Chromium-Monopols als gefährlicher. Erste Symptome gibt es ja bereits, seit dem Adblocker auf Chrome nicht mehr vollständig filtern können. Da ist es dann auch kein weiter Schritt mehr, Adblocker komplett aus der Chromium-Engine zu verbannen. Und was soll man dann tun, wenn 90% der Welt die selbe Browser-Engine nutzt und kaum noch eine Webseite einen anderen Browser unterstützt? Genau davor habe ich Angst.
+1
PorterWagoner
PorterWagoner04.03.22 10:49
Eine sehr interessante Diskussion hier in den Kommentaren! Das beleuchtet einen Aspekt, den ich als Nutzer so gar nicht wahrnehme. Man denkt als Anwender, dass es große Vielfalt bei Browsern gibt und merkt gar nicht, dass es vielleicht so wenig vielseitig zugeht wie 2002m, als der Internet Explorer alleine King of Internet war.
-1
Unwindprotect04.03.22 17:27
Metty
wicki
Das sehe ich anders. Cui bono?

Ich nehme Euch die negativen Bewertungen nicht übel. Für den Benutzer sind diese technischen Aspekte nicht offensichtlich und Apple kaschiert sie mit seinem Marketing ganz geschickt. Wer an den Details interessiert ist, den könnte dieser Artikel interessieren.

https://httptoolkit.tech/blog/safari-is-killing-the-web/

Als Webentwickler bin ich jedoch von Apple enttäuscht.

Das sehe ich ein wenig anders. Wenn man sich die Features anschaut, dann fällt auf - sie sind meistens lange vorher in Chrome implementiert worden. Warum ist das so? Weil Google so tolle Browser-Entwickler hat und so Pro-Web ist? Nein... weil diese Features intern bei Google entwickelt werden und wenn sie "fertig" sind, dann wird einfach eine Spec rausgehauen und es als "Standard" verkauft. Ab diesem Zeitpunkt wird massiv Advocacy betrieben. Oft finden dann erst die anderen Browser-Hersteller die teilweise peinlichen Spezifikations-Fehler (z.B. bei WebComponents V1 durch Safari-Entwickler).Ein Resultat des ganzen ist, dass viele Webentwickler selbst vor allem Chrome nutzen und präferieren. Für Google ist das die gleiche Strategie wie sie Microsoft seit einiger Zeit verfolgt: Umgarne die Entwickler und so beherrschst Du das Feld. Die Nutzer sind dabei meist ziemlich egal. Ziel ist vor allem der _weitere_ Ausbau des wachsenden Chrome-Monopols und damit der aktive Kampf gegen Datenschutz.

Wenn sich tatsächlich mal vorher auf ein Feature geeinigt wurde, dann kommt es durchaus vor, dass Chrome das einfach nicht implementiert und ein Feature dann trotz Standard einfach stirbt.

Der größte Feind des Web ist Google und Chrome.
0

Kommentieren

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