1 „Gefällt mir“
Seh das ehrlich gesagt nicht.
Leider findet man unter den Links auch keine wirklichen Beispiele wo genau das Problem liegen soll, evtl weil es keine gibt.
Heise sagt „In-App-Browser können Nutzer überwachen“ , das kannn die App aber sowieso. Apps sollten eigentlich auch keine externen Webseiten aufrufen, sondern die an den Standardbrowser weiterleiten.
„Die Auswahl des Standardbrowsers werde teilweise ignoriert, bemängeln die Experten.“
Wer das behauptet ist kein Experte.
Es geht hierbei um das Webcontrol des Betriebssystem. Das sollte man keineswegs durch Alternativen ersetzen, weil das ist extra dafür programmiert und abgesichert und auch den meisten Updates unterworfen. Hier andere Browser einzubinden würde alle Apps in Mitleidenschaft ziehen. Mal davon abgesehen das die Apps nicht damit getestet werden und noch nichtmal können, weil man die Browser die der User evtl auswählt nicht kennt.
Alternative Standardbrowser sind ansonsten natürlich sinnvoll. Unterbinden sollte man Sachen wie zb Windows das trotz Auswahl dir den Edge immer wieder aufdrängeln will oder Einstellungen „vergißt“.
Laut „Open Web Advocacy“ (open-web-advocacy.org):
In-App-Browser untergraben die Wahlmöglichkeiten der Benutzer, ersticken Innovationen, locken Benutzer in Apps, zerstören Websites und ermöglichen es Anwendungen, die Privatsphäre der Benutzer erheblich zu beeinträchtigen. In-App-Browser schaden Verbrauchern und Entwicklern und schädigen das gesamte Web-Ökosystem.
OWA traf sich kürzlich sowohl mit dem Digital Markets Act-Team als auch mit dem britischen Market Investigation Reference into Cloud Gaming and Browsers-Team, um zu diskutieren, wie Technologiegiganten die Wahl des Standardbrowsers der Benutzer über In-App-Browser untergraben und welchen Schaden dies verursacht.
In-App-Browser sind ein komplexes Thema. Um unsere Gedanken darzulegen, haben wir einen detaillierten 61-seitigen Antrag an die EU-Kommission verfasst, den wir heute öffentlich veröffentlichen.
Was sind In-App-Browser und welche Probleme verursachen sie?
Ein In-App-Browser kann geöffnet werden, wenn Benutzer in einer Nicht-Browser-App auf Links tippen. Anstatt die App zu verlassen und zum Standardbrowser des Benutzers zu wechseln, öffnen In-App-Browser einen Bereich innerhalb der nativen Host-App, um Webseiten darzustellen. Daher der Name „In-App-Browser“.
Wenn Sie auf einen Link zu einer Website eines Drittanbieters klicken, ignorieren viele beliebte Apps Ihre Wahl des Standardbrowsers und ersetzen Ihren Standardbrowser stattdessen automatisch und stillschweigend durch ihren eigenen In-App-Browser. Viele Benutzer – wahrscheinlich die meisten Benutzer! - sind sich nicht bewusst, dass dieser Wechsel stattgefunden hat.
Das Schlimmste ist, dass dieser Schalter diesen Apps die Möglichkeit gibt, Websites Dritter auszuspionieren und zu manipulieren. Beliebte Apps wie Instagram, Facebook Messenger und Facebook wurden dabei erwischt, wie sie JavaScript über ihre In-App-Browser in Websites Dritter einschleusten. TikTok führte Befehle aus, die im Wesentlichen ein Keylogger waren . Obwohl wir keinen Beweis dafür haben, dass diese Daten verwendet oder aus dem Gerät herausgefiltert wurden, ist das bloße Vorhandensein von JavaScript-Code, der diese Daten sammelt, in Verbindung mit dem Fehlen einer plausiblen Erklärung äußerst besorgniserregend.
Es ist möglich, In-App-Browser so zu nutzen, dass die Privatsphäre gewahrt bleibt. Sowohl iOS als auch Android bieten Systemkomponenten (SFSafariViewController bzw. Android Custom Tabs), die es der Hosting-App nicht ermöglichen, JavaScript einzuschleusen oder den Benutzer anderweitig auszuspionieren. Die Android Custom Tabs-Lösung ruft (standardmäßig) auch den Standardbrowser des Benutzers auf.
Dieses Verhalten wäre daher unmöglich, wenn Links einfach im Standardbrowser des Benutzers oder im vom System bereitgestellten In-App-Browser geöffnet würden.
Dies ist die Realität, mit der Benutzer heute auf ihren Mobiltelefonen konfrontiert werden. Es muss nicht so sein. Die Vorgabe, dass Apps die Browserwahl respektieren, ist nicht nur eine Frage der Bequemlichkeit; Es geht darum, sowohl Verbrauchern als auch Unternehmen die Möglichkeit zu geben, in einem offeneren, stabileren, funktionsreicheren, sichereren und privateren digitalen Ökosystem erfolgreich zu sein.
Auch die Missachtung der Browserwahl der Nutzer bremst Innovationen. Das Web gedeiht, wenn Browser hinsichtlich Funktionalität und Benutzererfahrung konkurrieren. In-App-Browser konkurrieren jedoch nicht als Browser. Viele, vielleicht sogar die meisten Benutzer sind sich nicht bewusst, dass sie ihnen aufgedrängt werden. Sie sind sich auch der damit verbundenen Qualitäts-, Sicherheits- und Datenschutzrisiken nicht bewusst. In-App-Browser agieren in einem Vakuum, immun gegen den Wettbewerbsdruck zur Verbesserung.
Diese Stagnation tut allen weh. Benutzer bleiben mit vergesslichen, minderwertigen In-App-Browsern hängen. Aufgrund fehlender Funktionen und Fehlern in Browsern, für deren Verwendung sich niemand entschieden hat, haben Unternehmen Schwierigkeiten, Zielgruppen zu erreichen und mit ihnen in Kontakt zu treten.
Die Lösung ist klar: Respektieren Sie die Browserwahl des Benutzers.
Die Verpflichtung, dass Nicht-Browser-Apps den Standardbrowser eines Benutzers für Websites Dritter verwenden, wird eine lebendigere und gerechtere digitale Landschaft ermöglichen. Benutzer profitieren von vertrauten Tools, denen sie vertrauen, und erleben Websites so, wie sie gestaltet wurden. Unternehmen und Verlage erhalten Zugang zu ihrem verdienten Publikum, ohne dass native App-Entwickler eingreifen müssen.
Das Eindringen von In-App-Browsern sowie die erheblichen Fehler, fehlenden Funktionen und kritischen Datenschutzbedenken, die sie mit sich bringen, sollten angegangen werden. Der Digital Markets Act und die britische MIR verfügen über alle notwendigen Durchsetzungsbefugnisse, um dieses Unrecht zu korrigieren.
Remote-Tab-In-App-Browser wie Android Custom Tabs sind für die meisten Benutzer eine potenziell ideale Lösung. Benutzerdefinierte Android-Registerkarten rufen standardmäßig den Standardbrowser des Benutzers auf und verhindern, dass die App JavaScript einfügt. Dies ist ein interessanter Mittelweg, bei dem der Benutzer (und die App) davon profitieren kann, den App-Kontext nicht zu verlassen und gleichzeitig die Wahl des Standardbrowsers durch den Benutzer zu respektieren und die Privatsphäre des Benutzers zu wahren. Allerdings ist es der hostenden nativen App derzeit möglich, benutzerdefinierte Android-Tabs an einen bestimmten Browser zu binden und die Auswahl des Benutzers als Standardbrowser zu überschreiben. Diese Fähigkeit muss entfernt werden.
Während der Remote-Tab-In-App-Browser von iOS (SFSafariViewController) verhindert, dass die App JavaScript einfügt, ist er an Safari (oder genauer gesagt an WkWebView) gebunden und überschreibt somit die Wahl des Standardbrowsers durch den Benutzer.
Wir haben 6 Abhilfemaßnahmen vorgeschlagen:
- Designierte Kernplattformdienste sollten die Wahl des Benutzers für den Standardbrowser respektieren. (DMA-spezifisch)
- App Store-Regeln müssen vorschreiben, dass Nicht-Browser-Apps den vom Benutzer gewählten Standardbrowser für http/https-Links zu Websites/Web-Apps von Drittanbietern verwenden.
- Apple muss SFSafariViewController (den vom System von Apple bereitgestellten In-App-Browser für iOS) aktualisieren, um die Wahl des Benutzers für den Standardbrowser zu berücksichtigen.
- Drittunternehmen müssen eine ausdrückliche und wirksame technische Abmeldung von nicht standardmäßigen In-App-Browsern erhalten.
- Betriebssysteme müssen ein globales Benutzer-Opt-out bieten. Apps müssen außerdem die ausdrückliche Erlaubnis der Benutzer einholen, um ihre Wahl des Standardbrowsers außer Kraft zu setzen.
- Google muss die Möglichkeit entfernen, die Wahl des Standardbrowsers eines Benutzers über benutzerdefinierte Android-Tabs (Googles vom System bereitgestellter In-App-Browser für Android) zu überschreiben.
Diese Abhilfemaßnahmen überschneiden sich und behandeln verschiedene Aspekte des Problems. Wenn diese Abhilfemaßnahmen umgesetzt werden, verhindern sie, dass Gatekeeper die Browserwahl des Benutzers untergraben, bieten Benutzern eine verbesserte Kontrolle über ihre Privatsphäre und Sicherheit und nehmen technische Korrekturen an den Grundlagen für das Laden von Webseiten vor. Diese Korrekturen projizieren die Browserauswahl eines Benutzers in von ihm verwendete Nicht-Browser-Apps und bieten Benutzern die Sicherheit, Privatsphäre, Stabilität und Funktionen, um die Browserkriege legitim ausgetragen werden. Es ist nicht mehr erlaubt, dass Apps Web-Traffic zu ihrem eigenen Vorteil zum Nachteil der Community als Ganzes abschöpfen.
Wir möchten insbesondere Lukasz Olejnik, Felix Krause, Jesper van den Ende, Stuart Langridge, Bruce Lawson und Adrian Holovaty für ihre Arbeit bei der Ausarbeitung dieses Falles danken. Wir sind auch dankbar für die breite Unterstützung und das Feedback, das wir von der Webentwicklungs- und Browserentwicklungs-Community erhalten haben.
Wir werden diese Angelegenheit weiter verfolgen, bis sie weltweit geklärt ist. Die Wahl des Browsers durch den Nutzer ist nur dann wichtig, wenn diese Wahl tatsächlich respektiert wird.
„die als datenschutzfreundlich gepriesenen In-App-Browser von Apple und Google“ und schon kann ich OWA nicht ernst nehmen… Zwei der datenschutzunfreundlichsten Unternehmen sollen datenschutzfreundliche in-app-browser haben? Aha…
Safari auf dem iPhone ist schon sehr datenschutzfreundlich und sicher, wenn man diesen richtig einstellt und die AdGuard App als Plugin dazu installiert. Das neue iOS ist ziemlich stark auf Datenschutz getrimmt, weil v.a. Firmen iPhones als Diensthandys ausgeben. UInd da ist nunmal Sicherheit und Datenschutz sehr wichtig. Da der Safari Apples Standardbrowser ist, hat dieser mittlerweile fast die selben restriktiven Sicherheitsoptionen wie das OS.
Das Problem an dem ganzen Sicherheitsgedöns bei iPhone/iOS ist die extrem eingeschränkte Bewegungsfreiheit des Nutzers. Man kann iOS nicht mehr jailbreaken, es gibt keinen Filebrowser der tief im System agiert, man kann nur über Umwege externe Apps installieren, man ist auf den AppStore angewiesen usw…
Der ganze Text machts eher noch schlimmer.
Die reiten immer wieder auf dem einen Punkt Auswahl des Inapp Browsercontrols rum, als würde man das nicht verstehen wenn mans nur einmal schreibt.
Bin mir nichtmal sicher ob das neue Gesetz überhaupt das Inapp Browsercontrols berührt. Da man dort wie gesagt nur das Anzeige Control benutzt, also null Handling, null Oberfläche.
Bleib dabei, die hätten mal jemand konsultieren sollen der sich damit auskennt.
Die ganze Organisation scheint mir eher auf Effekthascherei aus zu sein.
Das seh ich auch eher als Problem. Da ist man aber auch grade dran.
Allerdings muss man auch da aufpassen, das man mit Freiheit keine neuen Sicherheitslöcher reißt. Apples Bedenken sind da nicht ganz unbegründet.