Competition cops in Europe and the United Kingdom have started paying attention to in-app browsers, a controversial mechanism for presenting web content within native apps.

Open Web Advocacy (OWA), a group that supports open web standards and fair competition, said in a post on Tuesday that representatives "recently met with both the [EU's] Digital Markets Act team and the UK's Market Investigation Reference into Cloud Gaming and Browsers team to discuss how tech giants are subverting users' choice of default browser via in-app browsers and the harm this causes."

OWA argues that in-app browsers, without notice or consent, "ignore your choice of default browser and instead automatically and silently replace your default browser with their own in-app browser."

The group's goal isn't to ban the technology, which has legitimate uses. Rather it's to prevent in-app browsers from being used to thwart competition and flout user choice.

In-app browsers are like standalone web browsers without the interface - they rely on the native app for the interface. They can be embedded in native platform apps to load and render web content within the app, instead of outside the app in the designated default browser.

They've been around for mobile apps at least since 2008, when UIWebView debuted in iOS 2.0. UIWebView is a deprecated iOS API that was superseded by WKWebView in 2014. And the following year, Apple introduced SFSafariViewController, presently the recommended way to render web content in iOS apps.

Android has its own flavors, notably Android System WebView and Chrome Custom Tabs (CCTs). Some companies implement a bundled engine in-app browser, which is where the developer uses their own browser engine in lieu of a native platform WebView API. Meta does this with its Facebook app for Android, but not for iOS due to Apple's platform rules.

The problem with in-app browsers is that they play by a different set of rules from standalone browsers. As noted by OWA in its 62-page submission [PDF] to regulators:

• They override the user's choice of default browser
• They raise tangible security and privacy harms
• They stop the user from using their ad-blockers and tracker blockers
• Their default browsers privacy and security settings are not shared
• They are typically missing web features
• They typically have many unique bugs and issues
• The user's session state is not shared so they are booted out of websites they have logged into in their default browser
• They provide little benefit to users
• They create significant work and often break third-party websites
• They don't compete as browsers
• They confuse users and today function as dark patterns

Since around 2016, software engineers involved in web application development started voicing concerns about in-app browsers at some of the companies using them. But it wasn't until around 2019 when Google engineer Thomas Steiner published a blog post about Facebook's use of in-app browsers in its iOS and Android apps that the privacy and choice impact of in-app browsers began to register with a wider audience.

Steiner observed: "WebViews can also be used for effectively conducting intended man-in-the-middle attacks, since the IAB [in-app browser] developer can arbitrarily inject JavaScript code and also intercept network traffic." He added: "Most of the time, this feature is used for good."

Nonetheless, the possibility that in-app browsers might enable code injection and traffic interception for illegitimate purposes struck a nerve among those worried about privacy and security.

In August 2022, developer Felix Krause published a blog post titled "Instagram and Facebook can track anything you do on any website in their in-app browser." A week later, he expanded his analysis of in-app browsers to note how TikTok's iOS app injects JavaScript to subscribe to "every keystroke (text inputs) happening on third party websites rendered inside the TikTok app" but, according to the company, never uses that keylogging code.

A month later, multiple lawsuits were filed against Meta, already the defendant in numerous privacy and competition-related complaints that followed from the Facebook/Cambridge Analytica scandal.

The in-app browser lawsuits, which rely heavily on Krause's posts, were consolidated into a single case that was dismissed [PDF] by the plaintiffs at the end of October 2023.

Meta's argument for that outcome was that the surveillance potential of in-app browsers remained unrealized. In a reply [PDF] supporting its motion to dismiss, Meta's legal team wrote: "As Plaintiffs effectively concede, the Krause Post specifically disclaims any allegation that Meta monitors and records everything users do in the In-App Browser or violates the [Apple] ATT policy; rather, it merely purports to describe what app developers like Meta could theoretically do through the use of in-app browsers."

Even assuming one accepts Meta's and TikTok's claims that they've not misused the extraordinary access granted by in-app browsers - a difficult ask in light of allegations raised in ongoing Meta litigation - the issue remains that companies implementing in-app browsers may be overriding the choices of users regarding their browser and whatever extensions they have installed.

However, Meta does provide a way to opt out of having its in-app browser open links clicked in its Facebook and Instagram apps.

"If they choose, people can use the menu inside our in-app browser to select the option to open links inside the system browser," Meta explains. "Additionally, people who do not wish to use all the features of our technologies (including the in-app browser) are able to access Facebook and Instagram through the web instead of our apps."

Bill Budington, senior staff technologist for the Electronic Frontier Foundation, told The Register that the EFF hasn't taken a position on in-app browsers.

"I think it's a mixed bag, honestly: if an in-app browser has a different cookie pool and browser fingerprint, this makes it harder for trackers to identify you across different sites the in-app browsers visit," he said. "However, embedded browsers can also be used to skirt some of the privacy choices the user has made in their normal browser, and can deliver to the app containing it what sites you've visited and your behavior on those sites.

I'd recommend copying the link and pasting it into a dedicated browser, which has more granular privacy settings

"If someone is interested in some content an app has linked to and displays in an embedded browser, I'd recommend copying the link and pasting it into a dedicated browser, which has more granular privacy settings that can be toggled."

Jean-Paul Schmetz, CEO of Ghostery, told The Register that in-app browsers aren't as safe as standalone browsers. He said it depends upon the nature of the app that implements the in-app browser. For a developer who implements an in-app browser because it's easier than content presentation in native code, that's not great but it's probably OK, he said.

For large companies like Facebook, however, he expressed doubt, noting that the Facebook iOS app is able to see what people do on web pages rendered within its embedded in-app browser in a way that standalone browsers don't.

"None of the browsers that I know spy on the user that way," he said.

Jon von Tetzchner, CEO of browser maker Vivaldi, told The Register in a phone interview about an article written perhaps a decade ago by Tim Berners-Lee on closed systems.

"At the time he was talking about Facebook and the like," he said. "And it was a brilliant article... And I think the problem has increased because you're seeing applications trying to keep you inside their silos. And I think that's unfortunate."

"In many ways, obviously, it is a question of data collection. It's basically a question of control. The beauty of the web is that you can go anywhere and be anywhere on the web and you're not supposed to be locked in."

It's not helpful for the user and it's not helpful for, should we say, competition on the internet

"But obviously, some of the services really would like to lock you in. And the same applies to the gatekeepers. I mean, wanting to keep you inside their ecosystem where they're making money and as soon as you go out of the app environment and into the web, then they lose control. So, I mean, definitely in-app browsing, it's not helpful for the user and it's not helpful for, should we say, competition on the internet."

Tetzchner said he expects further regulatory intervention, at least in Europe.

"Obviously, there's already investigations going into both Apple and Google. Apple in that has been the worst so far. It's incredible. If you look at how they've implemented their choice screen and how they're dealing with allowing browsers that are not based on WebKit and how they introduced the Core Technology fee - they kind of make everyone else look pretty good. But the reality is all of those companies in different ways are trying to stay in control and keep competition at bay."

As for the Competition and Markets Authority (CMA), the UK watchdog appears to be willing to consider allowing developer choice to supersede user choice, or at least that was the case two years ago. In its 2022 response to the CMA's Interim Report, Google observed [PDF] that the competition agency itself had conceded that in an Android native app, the choice of browser belongs to the app developer rather than to Google.

"The Interim Report raises concerns about in-app browsers overriding users' chosen default browsers," Google said in its response. "However, as the CMA rightly notes, the decision on whether a native app launches an in-app browser, and if so, which browser, lies with the respective app developer, not Google. Having control over whether or not an in-app browser is launched allows app developers to customize their user interfaces, which can in turn improve the experience for users. There is therefore, to some extent, a trade-off between offering developers choice and offering end users choice." ®

https://www.theregister.com//2024/03/27/inapp_browsers/