Plattform-Neigung

 (mozilla.github.io)
1 Punkte von GN⁺ 2024-01-21 | 1 Kommentare | Auf WhatsApp teilen
  • Mozillas Platform Tilt verfolgt technische Bedingungen auf wichtigen Softwareplattformen, durch die Firefox gegenüber dem jeweiligen First-Party-Browser benachteiligt wird, und macht Wettbewerbsnachteile bei Sicherheit, Stabilität, Performance und Funktionen sichtbar
  • Bei Apple-bezogenen Themen sind die Probleme am weitesten verbreitet: vom Verbot von Browser-Engines Dritter über Einschränkungen bei Mehrprozess-Architektur, JIT und Accessibility-APIs unter iOS bis hin zu Standardbrowser-Einstellungen, Erweiterungen, Beta-Verteilung und dem Umgang mit Web-Apps auf dem Home-Bildschirm
  • Auf Google Android sind vor allem das Fehlen einer API zum Import von Browserdaten, Abläufe, bei denen Google-Apps statt des Standardbrowsers Chrome öffnen, sowie Fälle relevant, in denen Firefox für Android Suchergebnisseiten in geringerer Qualität ausgeliefert wurden
  • Unter Microsoft Windows ist es für Drittanbieter-Browser schwierig, den Standardbrowser programmatisch festzulegen, und Abläufe wie Search, Copilot und Widgets bevorzugen Edge
  • Gemeinsame Muster sind, dass die Wahl des Standardbrowsers durch Nutzer, der Datentransfer zwischen Browsern, Engine-Funktionen sowie die Zugänglichkeit von Verteilung, Tests und Erweiterungen plattformspezifisch zugunsten des jeweiligen eigenen Browsers wirken

Was Platform Tilt verfolgt

  • Platform Tilt ist ein Dashboard, das technische Fälle verfolgt, in denen Firefox auf wichtigen Softwareplattformen gegenüber dem First-Party-Browser benachteiligt wird
  • Im Fokus stehen Sicherheit, Stabilität, Performance und Funktionen; außerdem werden Änderungen vorgeschlagen, um ein ausgeglicheneres Wettbewerbsumfeld zu schaffen
  • Diskussionen zu aktuellen Themen laufen im platform-tilt issue tracker

Einschränkungen bei Browser-Engines und iOS-Funktionen auf Apple-Plattformen

  • App Store forbids third-party browser engines: Regel 2.5.6 der Apple App Store Review Guidelines verlangt, dass Apps zur Webnavigation das passende WebKit-Framework und WebKit JavaScript verwenden
    • Aufgrund dieser Richtlinie kann Firefox unter iOS nicht mit Gecko ausgeliefert werden
    • Das wirkt sich auch auf die Verteilung von Firefox über den App Store auf anderen Apple-Plattformen wie macOS aus
    • Die App-Store-Richtlinien sollten so geändert werden, dass Browser-Engines von Drittanbietern für Webbrowser erlaubt sind
  • Support for third-party multi-process applications on iOS: Moderne Webbrowser verwenden eine Mehrprozess-Architektur, darunter Prozesse pro Website und dedizierte Prozesse für sensible Funktionen wie die GPU
    • Safari nutzt unter iOS eine Mehrprozess-Struktur, aber Drittanbieter-Apps, die nicht Safaris WebKit-Engine verwenden, erhalten nicht denselben Mechanismus
    • iOS sollte einen Mechanismus bereitstellen, um isolierte Kindprozesse zu erstellen und effizient mit ihnen zu kommunizieren
    • Zu den Anforderungen gehören Anzahl und Lebensdauer von Kindprozessen je nach Navigationsverhalten des Nutzers, das Setzen eingeschränkter Berechtigungen, Messaging und Shared Memory, Shared-Memory-Bereiche mit Lese-/Schreib- oder Nur-Lese-Rechten, unabhängige Entitlements für Eltern- und Kindprozesse, das Laden von Bibliotheken innerhalb des Bundles sowie IOSurface-Rendering über Metal oder OpenGL und die prozessübergreifende Freigabe
    • Firefox verwendet auf mehreren Betriebssystemen eine gemeinsame Codebasis, daher sollten sich Schnittstellen und Verhalten der Prozessverwaltung weitgehend an andere Plattformen wie macOS und Android anlehnen
  • JIT Support on iOS: Um eine performante JavaScript-/WebAssembly-Engine ausliefern zu können, muss ein Browserprozess beschreibbare und zugleich ausführbare Speicherbereiche anlegen können
    • iOS-Apps können solche Speicherberechtigungen nicht mit dem Systemaufruf mmap(2) erzeugen
    • Für Safaris WebKit-Rendering-Engine gibt es eine Ausnahme, sodass sie beschreibbare und ausführbare Speicherbereiche anlegen kann
    • Unter macOS gibt es mit dem Hardened-Runtime-Entitlement com.apple.security.cs.allow-jit ein entsprechendes Modell; iOS sollte Nicht-WebKit-Browsern ein gleichwertiges Entitlement sowie die Berechtigung zur Nutzung der APIs pthread_jit_write_protect_np und sys_icache_invalidate geben
  • Accessibility APIs on iOS: Die Dokumentation der Accessibility-APIs unter iOS ist unvollständig, und viele APIs, die Webbrowser zur Unterstützung von Webstandards für Barrierefreiheit benötigen, sind nicht dokumentiert
    • WebKit scheint über ein proprietäres System-Bundle mit Closed Source zu verfügen, das zur Laufzeit geladen wird, wodurch sich selbst die Nutzungsweise schwer erschließen lässt
    • Einige Integer-Konstanten für Traits wie „visited“ und „radio button“ sowie Integer-Konstanten für Notification-Typen wie „value changed“ sind nicht öffentlich
    • Alle von WebKit verwendeten Accessibility-APIs sollten dokumentiert und stabil sein; idealerweise sollte WebKit sie ebenfalls auf dieselbe Weise nutzen wie Browser-Engines von Drittanbietern

Unterschiede bei Nutzererlebnis, Verteilung und Erweiterbarkeit auf der Apple-Plattform

  • Messages integration on iOS: Die Safari-Startseite auf iOS zeigt zuletzt in der Messages-App empfangene Links und gesendete Kontakte an, aber Drittanbieter-Browser können dieselbe Funktion nicht anbieten, da ihnen der Zugriff auf Messages-Daten fehlt.

  • Importing browser data on iOS: Auf iOS können Drittanbieter-Browser nicht auf Browserdaten wie Verlauf, Lesezeichen und Cookies zugreifen, und es gibt auch keine API zum Importieren.

    • Diese Daten sind sensibel, aber auf wichtigen Desktop-Plattformen sind ähnliche Importfunktionen möglich.
    • iOS kann den Zugriff auf sensible Daten wie bei Gesundheits- und Fitnessdaten mit Zustimmung der Nutzer vermitteln.
    • Wenn ein Datenimport nicht möglich ist, entsteht beim Wechsel von Safari zu einem anderen Browser Reibung.

  • Setting and checking default browser on iOS: iOS bietet Drittanbieter-Browsern keine Funktion, einen System-Prompt anzuzeigen, mit dem Nutzer die App als Standardbrowser festlegen können.

    • Android bietet über eine Anfrage der browser role eine ähnliche Funktion, macOS über LSSetDefaultHandlerForURLScheme und LSSetDefaultRoleHandlerForContentType.
    • iOS-Browser können nur per Deep Link zur Einstellungsoberfläche verweisen, und Nutzer müssen den Einstellungsbildschirm verstehen und die Änderung selbst vornehmen.
    • Auf iOS 17.2.1 gibt es Fälle, in denen bei der Suche in den Einstellungen nach „Default browser app“ oder „Default“ kein Ergebnis zum Ändern des Standardbrowsers angezeigt wird.
    • Drittanbieter-Browser können derzeit nicht einmal erkennen, ob sie der Standardbrowser sind; dadurch ist es schwierig, den Browser anhand der Nutzerabsicht zu optimieren oder zum passenden Zeitpunkt um eine Änderung des Standardbrowsers zu bitten.

  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS: Damit Nicht-WebKit-Browser password autofill, one-time codes, passkeys und Apple Pay unterstützen können, müssen sie associated domains auf Basis der Origin von Webinhalten angeben können.

    • WebKit-basierte Browser können die associated domain der Browser-App mit der Domain überschreiben, die der Nutzer gerade besucht.
    • Zum Beispiel muss der Browser in einem Passwortfeld auf example.com anzeigen, dass dieses Feld zur Origin von example.com gehört, damit der Passwortmanager im Geltungsbereich von example.com aufgerufen wird.
    • Für die Unterstützung von Apple Pay könnten zusätzliche Änderungen nötig sein, damit Zahlungen wie in Safari für registrierte Apple-Pay-Empfänger angenommen werden können.

  • Browser extension support on iOS: Safari unterstützt Erweiterungen, die über den iOS App Store verteilt werden, aber Drittanbieter-Browser können wegen der App Store Review Guidelines 2.5.2 nur schwer eigene Erweiterungsfunktionen anbieten.

    • Browser-Erweiterungen sind ein Kernelement des Web-Ökosystems und ermöglichen Entwicklern, Browser um Funktionen zu ergänzen und dadurch Utility, Nutzbarkeit und Interoperabilität mit System-Apps zu erhöhen.
    • Die Softwareanforderungen des App Store sollten gelockert werden, damit Drittanbieter-Browser eigene Erweiterungskataloge verwenden können.

  • Beta testing on iOS: Auf iOS können Beta-Versionen von Apps nicht über den App Store verteilt werden; stattdessen muss TestFlight verwendet werden.

    • TestFlight hat eine Begrenzung auf 10.000 Personen, was im Vergleich zur Größe der Beta-Nutzerschaft großer Browser klein ist.
    • Wenn das Limit erreicht ist, müssen ältere Nutzer manuell entfernt werden, was zusätzlichen Wartungsaufwand erzeugt.
    • Nutzer müssen die TestFlight-App installieren, einen access code anfordern, warten und dann den Code eingeben.
    • Neue Safari-Versionen sind in iOS-Betas enthalten und unterliegen daher nicht denselben Beschränkungen.
    • Als Lösungen werden vorgeschlagen, die Verteilung von Pre-Release-Builds von Browsern im App Store zu erlauben oder die Nutzergrenze von TestFlight aufzuheben und öffentliche Links unbegrenzt zu verteilen.

  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: Die Kontextmenüs Search Web oder Search with <Search Engine> unter iOS und macOS sowie die Such-Einstiegspunkte in den Services der macOS-Menüleiste führen Suchanfragen unabhängig vom Standardbrowser des Nutzers in Safari aus.

  • SFSafariViewController should respect the user’s default browser: SFSafariViewController ist eine High-Level-API, mit der iOS-Apps Webinhalte im Nutzerbrowser rendern lassen und zugleich in die App einbetten können.

    • Diese API verwendet immer die Safari-Version, unabhängig vom Standardbrowser des Nutzers.
    • Das Anzeigeerlebnis für Webinhalte ist inkonsistent, und Traffic fließt von alternativen Browsern ab.

  • Browsers with alternative engines should be able to ship a single binary & bundle on iOS: Apples aktueller Vorschlag verlangt, dass Browser-Anbieter, die ihre eigene Browser-Engine verwenden wollen, in der EU eine separate App verteilen, statt ihre bestehende App zu aktualisieren.

    • Bestehende EU-Nutzer müssten auf die neue App wechseln, was wahrscheinlich wenig praktikabel ist und Wettbewerbsbarrieren schafft.
    • Zu den von Firefox genannten Bedenken gehören Schwierigkeiten bei Auffindbarkeit und Migration von WebKit-Firefox zu Gecko-Firefox, der Verlust des Zugriffs für EU-Nutzer von Gecko-Firefox bei Aufenthalten außerhalb der EU von mehr als 30 Tagen sowie das Problem, dass Nicht-EU-Nutzer von WebKit-Firefox, die dauerhaft in die EU ziehen, auf einer nicht aktualisierten „verwaisten“ Version verbleiben.
    • Browser-Entwickler müssten zwei vollständig getrennte Apps entwickeln, pflegen und verteilen; dadurch entstehen Komplexität bei der Datenmigration, Nutzerabwanderung, geringere Akquise und Einschränkungen bei wiederholten A/B-Rollouts für iOS-Nutzer in der EU.
    • Als Alternative wird vorgeschlagen, weltweit ein einzelnes Binary und Bundle mit den Webviews beider Engines bereitzustellen, wobei das OS der App beim Start die BrowserEngineKit-Berechtigung mitteilt.

  • Webentwickler sollten iOS unabhängig vom Standort mit alternativen Browser-Engines testen können: BrowserEngineKit hatte bei der ersten Ankündigung eine Standortbeschränkung, die das Testen eigener Engines auf Geräten außerhalb der EU verhinderte

    • Diese Beschränkung wurde in 18.2 beta für lokale Entwicklung und Tests aufgehoben, besteht für Webentwickler jedoch weiterhin
    • Da auch Webentwickler außerhalb der EU EU-Nutzer unterstützen können, wird ein Mechanismus benötigt, mit dem sich Websites unabhängig vom Standort einfach mit alternativen Browser-Engines testen lassen

  • Browser mit alternativen Engines sollten Home-Screen-Web-Apps auf iOS installieren und verwalten können: Es gibt zwar eine API, mit der alternative Browser-Engines Web-Apps zum iOS-Home-Bildschirm hinzufügen können, diese Apps werden jedoch in Safari geöffnet

    • Vor und nach der Installation unterscheiden sich enginespezifische Funktionen, Nutzerstatus und Präferenzen, wodurch die Erfahrung getrennt wird
    • Apple hat sich aus Sicherheitsgründen dagegen ausgesprochen, das Rendern von Home-Screen-Web-Apps mit nicht-WebKit-Engines zu erlauben
    • Die grundlegenden Sicherheitsanforderungen für Home-Screen-Web-Apps entsprechen den Sandbox- und Isolationsanforderungen zwischen Websites, die bereits beim normalen Surfen im Web gelten
    • Android delegiert das Rendern von Web-Apps seit Jahren an Browser-Engines von Drittanbietern; iOS sollte dies ebenfalls ermöglichen

Datenübernahme, Standardbrowser und Sucherlebnis bei Google Android

  • Importing browser data on Android: Unter Android sind Browsing-Daten wie Verlauf, Lesezeichen und Cookies für Drittanbieter-Browser nicht zugänglich
    • Die Daten werden im data directory der Webbrowser-App gespeichert, auf das Drittanbieter-Browser nicht direkt zugreifen können
    • Es gibt auch keine API und keinen ContentProvider, die den Import ermöglichen würden
    • Das Fehlen einer Importfunktion schafft große Reibung beim Wechsel von Chrome zu einem anderen Browser
  • Some Android features launch Chrome instead of the user’s default browser: Vorinstallierte Funktionen der Google application wie Google Search und Discover ignorieren die Wahl des Standardbrowsers durch den Nutzer und öffnen Links zu externen Websites immer in Chrome
    • Zusätzliche Einstiegspunkte gibt es auch in integrierten Funktionen wie dem Suchfeld auf dem Startbildschirm und dem App-Launcher
    • Jedes Mal, wenn ein Link in Chrome geöffnet wird, wird der Nutzer von seinem Standardbrowser weggeführt
    • Alle integrierten Apps und Funktionen, die externe Links öffnen, sollten diese im Standardbrowser des Nutzers öffnen
  • Lower quality search result pages in third-party browser engines on Android: Unter Android ist das Websucherlebnis eng mit verschiedenen integrierten Funktionen verzahnt, und es gab Fälle, in denen Firefox Suchergebnisseiten von geringerer Qualität als Chrome erhielt
    • Bei identischen Suchanfragen erhielt Firefox Android Seiten mit weniger Informationen und geringerer Designqualität als Chrome
    • Streng genommen ist dies ein Problem der Google-Search-Website, doch wegen der Bedeutung und des Integrationsgrads der Suche auf Android führt es zu einer Lücke im Nutzungserlebnis, die von der Wahl eines Drittanbieter-Browsers abschreckt
    • Es gibt keine technische Einschränkung, die das Funktionieren dieser Seiten in Firefox verhindern würde
    • Der Status dieses Issues ist closed

Edge-bevorzugende Abläufe in Microsoft Windows

  • Setting default browser on Windows: Windows bietet keine Funktion, mit der Drittanbieter-Browser programmgesteuert anfordern können, als Standardbrowser festgelegt zu werden
    • Auch nach der Browser-Installation müssen Nutzer selbst in die Betriebssystemeinstellungen wechseln und die Auswahl manuell treffen, was Reibung und Trägheit zugunsten der weiteren Nutzung von Edge erzeugt
    • Android und macOS bieten über System-Prompts oder entsprechende APIs ein Muster, bei dem Nutzer leicht zustimmen oder ablehnen können
    • Unter Windows 10 sind in der Einstellungsoberfläche mehrere Klicks und eine doppelte Bestätigung nötig; unter Windows 11 gibt es zwar eine Schaltfläche Set default, doch das reicht nicht aus
  • Default browser is set to Edge by several Windows flows: Windows 10 und 11 zeigen fortlaufend Hinweise an, dass Microsoft Edge der „recommended“ Browser für Windows sei, und bieten UI-Elemente an, um den Standardbrowser auf Edge umzustellen
    • In manchen Formulierungen wird dazu aufgefordert, „recommended browser settings“ zu übernehmen, ohne die Änderung des Standardbrowsers klar offenzulegen
    • Beispiele werden auf automatisch eingeblendeten UI-Oberflächen wie bei Windows-Updates hinzugefügt und entfernt und ändern sich fortlaufend
    • Windows-Komponenten können den Standardbrowser des Nutzers direkt ändern, während Drittanbieter-Browser den ms-settings:-Protokoll-Deep-Link verwenden müssen
    • Auch Windows sollte dieselben Funktionen und APIs verwenden, die Drittanbieter-Browsern zur Verfügung stehen
  • Some Windows features launch Edge instead of the user’s default browser: Mindestens drei zentrale Funktionen von Windows öffnen URLs nicht im aktuell eingestellten Standardbrowser, sondern in Microsoft Edge
    • Windows Search oder die Suche im Startmenü erscheint über das Suchfeld bzw. die Suchschaltfläche in der Taskleiste, Eingaben im Startmenü oder das Kürzel WIN+S; sowohl Suchergebnisse als auch Artikellinks werden in Edge geöffnet
    • Windows Copilot erscheint unter Windows 11 als am rechten Bildschirmrand angedocktes Fenster und öffnet Links in Antworten oder im Rendering-Bereich in Edge
    • Widgets heißen unter Windows 10 „news and interests“, zeigen Informationen wie Nachrichten, Wetter, Aktien und Sportergebnisse an und öffnen Links zu Webseiten in Edge

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-21
Meinungen auf Hacker News

  • Sowohl Android als auch Microsoft haben wohl Apps, die Links nicht im vom Nutzer gewählten Browser öffnen, sondern auf ihre eigene Weise. Das größere Problem ist jedoch, dass beim Antippen von Links innerhalb von Apps eine eingebaute WebView wie ein Browser geöffnet wird.
    Die App kann die Web-Aktivitäten darin überwachen. Ich würde mir wünschen, dass Android Play Store und iOS App Store erzwingen, dass alle Websites von Drittanbietern im Browser des Nutzers geöffnet werden.
    Man könnte Apps in „Webbrowser“ und „kein Webbrowser“ einteilen und Apps der Kategorie „kein Webbrowser“ nur eine kurze Liste von etwa 5–10 zugänglichen Domains registrieren lassen; den Rest würde das Betriebssystem blockieren.
    Apps wie Facebook, FB Messenger oder Google Maps, deren Hauptzweck nicht das Web-Browsing ist, kann man eindeutig als „kein Webbrowser“ ansehen.
    So ließe sich das Überwachungsproblem eingebauter WebViews verhindern, und man könnte Passwörter, Adressen, Lesezeichen und Verlauf, die im Browserprofil synchronisiert sind, unverändert nutzen. Wenn ich die Welt frei festlegen könnte, würde ich für Apps, die Links öffnen, außerdem ein Kontextmenü „In privatem Browserfenster öffnen“ verlangen.

    • Persönlich sehe ich das genauso, aber ich habe kürzlich gelernt, dass die meisten Nutzer das nicht so sehen. Als ich die autotempest-App veröffentlicht habe, ließ ich alle Drittanbieter-Links, die direkt zu Fahrzeugdetailseiten verschiedener Websites führen, im Standardbrowser des Nutzers öffnen. Die Nutzer mochten das nicht und wollten sehr deutlich, dass sie innerhalb der App geöffnet werden.
      Also habe ich das Öffnen innerhalb der App zum Standard gemacht, aber die Option beibehalten, den Standardbrowser zu verwenden.
    • Das Problem der In-App-Browser zu lösen, ist eine der obersten Prioritäten von Open Web Advocacy. Allerdings wird es dadurch kompliziert, was im Rahmen des Digital Markets Act möglich ist.
      Ich stimme zu, dass es ein wirklich wichtiges Thema ist; wer helfen möchte, soll sich bitte an Open Web Advocacy wenden.
    • Google hat stattdessen die Funktion Custom Tabs entwickelt, um Android-Entwickler in die genau entgegengesetzte Richtung zu drängen.
      Selbst wenn eine App nur eine nicht zusammenhängende Seite öffnet, etwa einen vom Nutzer bereitgestellten Link, wird empfohlen, sie statt im Standardbrowser in einem „Custom Tab“ zu öffnen. Der ausdrücklich genannte Zweck ist, dass der Nutzer die App nicht verlässt und so das Engagement erhalten bleibt.
      Natürlich gibt es keine systemweite Einstellung, die Nutzer abschalten könnten; man muss die Einstellung pro App suchen und hoffen, dass es überhaupt eine gibt.
      https://android-developers.googleblog.com/2023/02/bringing-b...
    • Bis zu einem gewissen Grad ist das bereits möglich, man kann auf „Im Browser öffnen“ tippen. Ob das allerdings in Googles Interesse liegt, weiß ich nicht.
      Es sind inzwischen neun Hauptversionen vergangen, seit Android Runtime-Berechtigungen etwa für die Kamera eingeführt hat, aber Internetzugriff erfordert immer noch keine Berechtigung.
    • Ich frage mich, ob „den WebView-Kontext zu sandboxen, damit er sich nicht mit tatsächlichen Web-Browsing-Aktivitäten oder WebViews anderer Apps überschneidet“ aus Punkt 2–4 nicht im Widerspruch zu Punkt 1 steht, nämlich dass es gefährlich ist, wenn die App ihre eigene WebView kontrollieren kann.
      Unklar ist auch, was „zugängliche Domains“ in der Praxis bedeuten soll. Prüft man nur die Domain der explizit aufgerufenen URL, ist das zu locker und leicht zu umgehen; prüft man jede Request-URL, ist das zu streng, sodass viele Entwickler nicht einmal ihre eigene Website korrekt laden könnten.

  • Dass Mozilla problematisiert, dass der „App Store Browser-Engines von Drittanbietern verbietet“, ist berechtigt, aber ich weiß nicht, ob man an diesem Faden ziehen möchte.
    Weil es auf iOS-Geräten ein Safari-Monopol gibt, kümmern sich ziemlich viele Entwickler um Unterstützung jenseits von Chrome. Im Moment müssen sie es zwangsläufig tun.
    Wenn bei Nutzern die Botschaft ankommt: „Die kaputte Funktion ist in Chrome nicht kaputt“, ist das der Weg in ein Monopol, und danach braucht Google bei neuen Webstandards deutlich weniger Konsens.
    Der aktuelle Zustand ist schon ein Chaos, aber es könnte noch schlimmer werden. Ich hoffe, dass diese Prognose falsch ist.

    • Auf iOS gegen das von Apple erzwungene Safari-Monopol vorzugehen, liegt natürlich im Interesse von Mozilla. Nur weil Chrome auf iOS ebenfalls unterdrückt wird, ist es für Firefox nicht von Vorteil, dass auch Firefox unterdrückt wird.
      Wenn Apples Beschränkungen wegfallen, die Firefox daran hindern, Gecko und Gecko-basierte WebExtensions umzusetzen, insbesondere Adblocker, dürfte der Marktanteil von Firefox auf iOS zwangsläufig steigen.
      Die dadurch entstehenden iOS-Firefox-Nutzer könnten ihren Desktop-Firefox mit dem iOS-Firefox samt Adblocking synchronisieren und so dazu gebracht werden, Firefox auch auf dem Desktop zu verwenden.
    • Genau das wollte ich auch sagen. Dass Safari auf iOS nicht durch Chrome ersetzt werden kann, ist – ob gut oder schlecht – der einzige Mechanismus, der eine vollständige Chrome-Dominanz verhindert.
    • Wenn es auf iOS freien Wettbewerb gäbe, würden meiner Ansicht nach viele Menschen Chrome installieren. Besonders wohl die meisten PC-Nutzer, deren einziges Apple-Gerät ein iPhone ist.
    • Der Grund, warum ich meine Website in Firefox zum Laufen bringe, ist nicht, dass sie auch in Safari laufen muss.
      Firefox funktioniert normalerweise einfach, und selbst wenn nicht, macht Safari als vernachlässigte Plattform, die ständig Zusatzarbeit erfordert, nicht gerade Lust, sich noch um einen weiteren Tech-Stack zu kümmern.
    • Wenn Mozilla Apple nicht zum Thema macht, können Beschwerden über andere Unternehmen ebenfalls mit Verweis auf Safari ignoriert werden. Weil Mozilla mit seiner Kritik an Apples Verhalten recht hat, wirkt es heuchlerisch, Google/Microsoft zu kritisieren und Apple auszuklammern.
      Ich bin die Argumente leid, die den Status quo verteidigen. Der Status quo entwickelt sich nicht in eine gute Richtung und wird sich ohne entschlossene Maßnahmen nicht ändern. Auch auf der Seite, die Apples Status quo verteidigt, scheint es keinen Plan zu geben, wie es künftig besser werden soll.
      Safari allein reicht nicht aus, um die Chrome-Dominanz zu verhindern, und nachdem die App-Store-Regeln der EU durchgesetzt wurden, ist die Wahrscheinlichkeit nicht gering, dass eine Öffnung der Browser-Engines erzwungen wird; langfristig ist also nicht einmal der Status quo selbst garantiert.
      Wir befinden uns gerade am Ende einer US-Regierung, die historisch eine starke Bereitschaft zu Kartellrechtsdurchsetzung gegenüber Tech-Unternehmen gezeigt hat. Viele verstehen nicht ausreichend, wie kartellrechtsfreundlich die Biden-Regierung ist.
      Diese Regierung könnte weitere vier Jahre im Amt bleiben oder auch nicht; angesichts dieser Unsicherheit ist dies eine der besten Gelegenheiten seit den frühen Windows-Kartellverfahren, tatsächliche Eingriffe bei Google/Apple/Microsoft zu verlangen.
      Eine kartellrechtlich offene Regierung, ein Wandel der Verbraucherstimmung gegenüber Big Tech, der Druck auf Apple rund um iOS und Googles Vorstoß im Juni, Adblocker zu schwächen, kommen jetzt zusammen – ein guter Zeitpunkt, um mit Nachdruck auf eine Änderung des Status quo zu drängen.
      Das ist nicht ohne Risiko, aber weiteres Warten verbessert die Lage nicht. Je länger man wartet, desto weniger relevant wird Firefox, desto größer wird die Wahrscheinlichkeit eines Regierungswechsels, und desto schwerer wird es für Mozilla, die öffentliche Meinung zu nutzen.
      Es wird keinen Moment geben, in dem Mozilla dieses Argument zu 100 % leicht gewinnen kann; wenn sie es jetzt nicht tun, werden sie am Ende vollständig aus dem Markt gedrängt.
      Ich unterstütze es, alle – einschließlich Apple – mit voller Kraft zur Rede zu stellen. Wenn man nach einer Öffnung von iOS eine Chrome-Dominanz befürchtet, sollte man dieses Problem durch Regulierung von Google angehen, und jetzt ist der beste Zeitpunkt, dieses Argument vorzubringen.

  • Als Android-Nutzer ist der Hauptgrund, warum ich Firefox nicht verwende, nicht wettbewerbswidriges Verhalten, sondern dass er sich langsam anfühlt.
    In Firefox verschiebt sich beim Laden der Startseite häufig das Layout, die Tastaturanimation ruckelt manchmal, und die Menüoption „Loslassen zum Auswählen“ kann ich nicht verwenden.

    • Ich benutze ihn seit Jahren und habe so einen Unterschied nie bemerkt.
    • Was ist „Loslassen zum Auswählen“?
    • In Firefox funktionieren auch die standardmäßigen Tastaturnavigations-Shortcuts externer Tastaturen überhaupt nicht.

  • https://github.com/mozilla/platform-tilt/issues/3
    JIT-Unterstützung auf iOS ist ein Faktor, der in der Diskussion darüber, dass „die EU Rendering-Engines von Drittanbietern auf iOS erzwingen wird“, viel zu wenig behandelt wird.
    Wird Apple Apps JIT-Unterstützung erlauben? Wird es eine neue Berechtigung geben, die Browser-Entwickler beantragen müssen? Interessant wäre es, aber danach sieht es eher nicht aus.

  • Zugehöriger Beitrag: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    Ich komme von https://news.ycombinator.com/item?id=39059255, aber dort gibt es keine Kommentare.

  • Wenn man unter macOS einen markierten Bereich rechts anklickt und Websuche auswählt, öffnet sich immer Safari, selbst wenn man einen anderen Standardbrowser festgelegt hat. Vielleicht passiert das nur in Mail.app, aber dieser Punkt scheint ausgelassen worden zu sein.

  • Die größte Beschwerde bei Firefox für Android ist, dass manchmal einfach nichts passiert, wenn man eine Domain in die Adressleiste eingibt und Enter drückt.
    Dieses Verhalten ist unregelmäßig und betrifft nur einige Websites wie https://forum.syncthing.net.
    Tabs zu schließen oder andere Tabs zu verwenden hilft nicht; erst ein erzwungenes Beenden der App behebt es.

    • Dasselbe Problem gibt es auch auf dem Desktop. Sie haben wohl eine Änderung an der Adressleiste eingebaut, die praktisch nichts verändert, und sich in einem Blogpost dafür gefeiert; dabei haben sie offenbar eine asynchrone Race Condition geschaffen und sie seit Jahren kaputt gelassen.
      Trotz aller Beschwerden ist es immer noch besser als der Google-Browser.
    • Habe ich auch. Extrem nervig. Manchmal stürzt er auch zufällig ab; das hat vor etwa einem Monat angefangen.

  • Das meiste ist nachvollziehbar, aber der Punkt zur Messages-Integration unter iOS fühlt sich nicht gut an.
    Eine API für „zuletzt gesendete Links“, bei der der Nutzer auswählen muss, wäre wohl unproblematisch, aber vollständigen Zugriff auf Nachrichtendaten würde ich einer Drittanbieter-App niemals erlauben wollen, selbst wenn Mozilla der Entwickler ist.
    Bei iOS-Erweiterungen kann Orion Erweiterungen sowohl aus der Chrome- als auch aus der Firefox-Erweiterungsgalerie installieren; das legt nahe, dass dies entweder kein echtes Problem ist oder dass es nach bestandener App Review seit Jahren so weiterbesteht.

  • Kopieren und Einfügen in Google Colab funktioniert in Chrome richtig, in Firefox aber nicht.

  • Es heißt, „Browsing-Informationen wie Verlauf, als Lesezeichen gespeicherte Websites und Cookies seien für Drittanbieter-Browser unter Android nicht zugänglich“ — aber warum sollte ich als Nutzer wollen, dass eine Drittanbieter-App auf den Verlauf, die Lesezeichen und Cookies meines Browsers zugreift?
    Das ist eindeutig ein Privacy Leak. Firefox soll nur die Daten bekommen, die Firefox erzeugt hat, während ich Firefox nutze, und keine Daten aus anderen Kontexten.

    • Ein Leak ist es nur, wenn der Zugriff ohne Erlaubnis erfolgt. Dass eine App den Zugriff auf diese Daten anfragen kann, während der Nutzer auch „auf keinen Fall“ sagen kann, ist an sich kein Problem.
    • Als Nutzer, der einfach zu einem neuen Browser wechseln möchte, will ich, dass der neue Browser auf Lesezeichen und andere Daten des alten Browsers zugreifen kann, um den Prozess zu erleichtern.
    • Es geht hauptsächlich um Import/Export mit anderen Browsern. Das ist beim Onboarding eine sehr übliche Aufgabe.
    • Bei Verlauf und Cookies kann man sicher dagegen sein, aber Lesezeichen zu exportieren und wieder zu importieren ist unverzichtbar.
      Firefox für Android unterstützt aber nicht einmal das :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • Das wirkt wie eine etwas unredliche Auslegung. Kontakte und andere sensible Daten können bereits ohne „Privacy Leak“ importiert werden.
      In dem Issue wird auch keine ungeprüfte Importfunktion gefordert, sondern darauf hingewiesen, dass Android den Zugriff auf andere sensible Daten mit Zustimmung des Nutzers vermitteln kann.