In-app browsers are still a privacy, security, and choice problem
(2024/03/27)
- Reference: 1711542615
- News link: https://www.theregister.co.uk/2024/03/27/inapp_browsers/
- Source link:
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 [1]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."
[2]
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.
[3]
[4]
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. [5]UIWebView is a deprecated iOS API that was superseded by [6]WKWebView in 2014. And the following year, Apple introduced [7]SFSafariViewController , presently the recommended way to render web content in iOS apps.
[8]
Android has its own flavors, notably Android System [9]WebView and [10]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 [11]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 [12]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 [13]man-in-the-middle attacks , since the IAB [in-app browser] developer can arbitrarily [14]inject JavaScript code and also [15]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.
[16]
In August 2022, developer Felix Krause published a [17]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 [18]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 [19]lawsuits were filed against Meta, already the defendant in numerous privacy and competition-related complaints that followed from the Facebook/Cambridge Analytica scandal.
[20]The way Apple, Alphabet implemented DMA rules 'seems to be at odds' with law
[21]Meta, Microsoft, X, Match pledge selves to Epic battle against Apple App Store
[22]Ten nations tell social media, banks, and telcos to get better at stopping scams
[23]No App Store needed: Apple caves, will allow sideloading in EU
The in-app browser lawsuits, which rely heavily on Krause's posts, were consolidated into a single case that was [24]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 [25]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 [26]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 [27]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 [28]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." ®
Get our [29]Tech Resources
[1] https://open-web-advocacy.org/blog/in-app-browsers-the-worst-erosion-of-user-choice-you-havent-heard-of/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://developer.apple.com/documentation/uikit/uiwebview
[6] https://developer.apple.com/documentation/webkit/wkwebview
[7] https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://developer.android.com/develop/ui/views/layout/webapps/webview
[10] https://developer.chrome.com/docs/android/custom-tabs/
[11] https://open-web-advocacy.org/files/OWA%20-%20DMA%20Interventions%20-%20In-App%20Browsers%20v1.2.pdf
[12] https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/
[13] https://en.wikipedia.org/wiki/Man-in-the-middle_attack
[14] https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface(java.lang.Object,%20java.lang.String)
[15] https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldInterceptRequest(android.webkit.WebView,%20android.webkit.WebResourceRequest)
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[17] https://krausefx.com/blog/ios-privacy-instagram-and-facebook-can-track-anything-you-do-on-any-website-in-their-in-app-browser
[18] https://krausefx.com/blog/announcing-inappbrowsercom-see-what-javascript-commands-get-executed-in-an-in-app-browser
[19] https://www.theregister.com/2022/09/23/meta_app_tracking/
[20] https://www.theregister.com/2024/03/25/ec_antitrust_team_opens_dma/
[21] https://www.theregister.com/2024/03/21/meta_microsoft_x_match_pledge/
[22] https://www.theregister.com/2024/03/14/global_fraud_summit_communique_meta/
[23] https://www.theregister.com/2024/03/12/apple_update_eu_devs_can_distribute_from_websites/
[24] https://storage.courtlistener.com/recap/gov.uscourts.cand.400497/gov.uscourts.cand.400497.95.0.pdf
[25] https://storage.courtlistener.com/recap/gov.uscourts.cand.400497/gov.uscourts.cand.400497.79.0.pdf
[26] https://www.facebook.com/business/help/206578174518231
[27] https://vivaldi.com/
[28] https://assets.publishing.service.gov.uk/media/6229ac568fa8f526d0002b05/Google.pdf
[29] https://whitepapers.theregister.com/
Open Web Advocacy (OWA), a group that supports open web standards and fair competition, said in [1]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."
[2]
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.
[3]
[4]
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. [5]UIWebView is a deprecated iOS API that was superseded by [6]WKWebView in 2014. And the following year, Apple introduced [7]SFSafariViewController , presently the recommended way to render web content in iOS apps.
[8]
Android has its own flavors, notably Android System [9]WebView and [10]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 [11]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 [12]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 [13]man-in-the-middle attacks , since the IAB [in-app browser] developer can arbitrarily [14]inject JavaScript code and also [15]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.
[16]
In August 2022, developer Felix Krause published a [17]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 [18]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 [19]lawsuits were filed against Meta, already the defendant in numerous privacy and competition-related complaints that followed from the Facebook/Cambridge Analytica scandal.
[20]The way Apple, Alphabet implemented DMA rules 'seems to be at odds' with law
[21]Meta, Microsoft, X, Match pledge selves to Epic battle against Apple App Store
[22]Ten nations tell social media, banks, and telcos to get better at stopping scams
[23]No App Store needed: Apple caves, will allow sideloading in EU
The in-app browser lawsuits, which rely heavily on Krause's posts, were consolidated into a single case that was [24]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 [25]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 [26]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 [27]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 [28]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." ®
Get our [29]Tech Resources
[1] https://open-web-advocacy.org/blog/in-app-browsers-the-worst-erosion-of-user-choice-you-havent-heard-of/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://developer.apple.com/documentation/uikit/uiwebview
[6] https://developer.apple.com/documentation/webkit/wkwebview
[7] https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://developer.android.com/develop/ui/views/layout/webapps/webview
[10] https://developer.chrome.com/docs/android/custom-tabs/
[11] https://open-web-advocacy.org/files/OWA%20-%20DMA%20Interventions%20-%20In-App%20Browsers%20v1.2.pdf
[12] https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/
[13] https://en.wikipedia.org/wiki/Man-in-the-middle_attack
[14] https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface(java.lang.Object,%20java.lang.String)
[15] https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldInterceptRequest(android.webkit.WebView,%20android.webkit.WebResourceRequest)
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZgRQq9Ld6t1Qa6X4dAeR7gAAAMk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[17] https://krausefx.com/blog/ios-privacy-instagram-and-facebook-can-track-anything-you-do-on-any-website-in-their-in-app-browser
[18] https://krausefx.com/blog/announcing-inappbrowsercom-see-what-javascript-commands-get-executed-in-an-in-app-browser
[19] https://www.theregister.com/2022/09/23/meta_app_tracking/
[20] https://www.theregister.com/2024/03/25/ec_antitrust_team_opens_dma/
[21] https://www.theregister.com/2024/03/21/meta_microsoft_x_match_pledge/
[22] https://www.theregister.com/2024/03/14/global_fraud_summit_communique_meta/
[23] https://www.theregister.com/2024/03/12/apple_update_eu_devs_can_distribute_from_websites/
[24] https://storage.courtlistener.com/recap/gov.uscourts.cand.400497/gov.uscourts.cand.400497.95.0.pdf
[25] https://storage.courtlistener.com/recap/gov.uscourts.cand.400497/gov.uscourts.cand.400497.79.0.pdf
[26] https://www.facebook.com/business/help/206578174518231
[27] https://vivaldi.com/
[28] https://assets.publishing.service.gov.uk/media/6229ac568fa8f526d0002b05/Google.pdf
[29] https://whitepapers.theregister.com/
alain williams
some garbled website address that goes through FB's servers
Something similar happens on youtube - it shows a clean URL but copy the link and it starts https://www.youtube.com/redirect?event=xxx . This is not obvious and lets youtube collect personal information -- both of which are against the GPDR; not that our chocolate teapot ICO will bother to do anything about it.
Pope catholic?
ThatOne
Any in-app browser is as (un)trustworthy as the app itself, plus the caveat that it's usually a quick-and-dirty piece of borrowed code thrown in to make the app a "whole experience", prevent the suck user from leaving, and of course, last but not least, to gather some juicy "telemetry" and ad revenue.
What's not to like?...
Re: Pope catholic?
iron
> it's usually a quick-and-dirty piece of borrowed code thrown in to make the app a "whole experience"
No it isn't. It is always an OS provided web view of some form. If that code is borrowed or shoddy your complaint is with Apple or Google.
Re: Pope catholic?
Jamie Jones
On android, you could say "often", but not "always"
There's nothing stopping you embedding whatever webview code you want. In fact. Mozilla makes "Geckoview" ( [1]https://wiki.mozilla.org/Mobile/GeckoView ) for that very purpose.
(I'm not calling geckoview "quick and dirty" - just citing it as an example of a third party "webview")
[1] https://wiki.mozilla.org/Mobile/GeckoView
Test Man
For me the absolute reason why I hate these in-app browsers is because they do not contribute to my History list, so I don't know whether I visited particular sites, nor do they allow me to utilise my existing autofill texts.
I really hate Facebook, Instagram and Threads' in-app browsers, and being forced to use them. There is only one reason they are utilising it - in order to more easily see what people are clicking on.
Hubert Cumberdale
Hmm. General agreement here, but the potential upvote I might've given was cancelled out by the two uses of "utilis[e/ing]" when "us[e/ing]" would have been fine. This is a niggle I have to correct in papers every day, so I'm perhaps disproportionately irritated by it.
I am David Jones
“Correcting” implies an error, which is manifestly not the case as utilise is a real word with a real meaning. Trying to impose your own linguistic style/preferences on an internet forum is a dick move, if I may be so bold.
Downvote from me.
Jamie Jones
As "in app browsing" was designed as a way to help developers render their app, it should be restricted to same-domain only (based on a single, hard-coded domain of the apps choice)
Visiting third party sites is no longer part of the app, it's browsing, and should be handed to the browser of users choice.
Robert Carnegie
I dunno. If I write an app that needs to display HTML, I feel that I don't want users to install DeadCat as their web browser, cause my app to not work with it, and then complain to my support forum when it doesn't work. Of course, I don't have to go near the support forum, so, problem solved - but I still don't like it. Or what if the user installs a malware fork of DeadCat instead, and hacks my app?
Jamie Jones
As I wrote above, I think in-app-browsing restricted to one domain of your choice would be the way to go.
You can then use it to render YOUR html in your app, but once you provide a user with an offsite link, that goes from app-rendering-html to browsing, and should then spawn the external browser.
I find it very infuriating that I cannot copy the website address from Instagram and that my adblocks are unavailable on the web browser used by insta. Also whenever there is a link in Facebook in a web browser, there is always some garbled website address that goes through FB's servers and therefore I cannot get a clean website address.
This also needs to be addressed.