A long, long time ago, Android treated browser tabs in a very unique way. Individual tabs were were seen as ‘applications’, and would appear interspersed with the recent applications list as if they were, indeed, applications. This used to be one of my favourite Android features, as it made websites feel very well integrated into the overall user experience, and gave them a sense of place within your workflows.
Eventually, though, Google decided to remove this unique approach, as we can’t have nice things and everything must be bland, boring, and the same, and now finding a website you have open requires going to your browser and finding the correct tab. More approachable to most people, I’d wager, but a reduction in usability, for me. I still mourn this loss.
Similarly, we’ve seen a huge increase in the use of in-application browsers, a feature designed to trap users inside applications, instead of letting them freely explore the web the moment they click on a link inside an application. Application developers don’t want you leaving their application, so almost all of them, by default, will now open a webview inside the application when you click on an outbound link. For advertising companies, like Google and Facebook, this has the additional benefit of circumventing any and all privacy protections you may have set up in your browser, since those won’t apply to the webview the application opens.
This sucks. I hate in-application browsers with a passion. Decades of internet use have taught me that clicking on a link means I’m opening a website in my browser. That’s what I want, that’s what I expect, and that’s how it should be. In-application webviews entirely break this normal chain of events; not because it improves the user experience, but because it benefits the bottom line of others.
It’s also a massive security risk.
Worst of all, this switch grants these apps the ability to spy and manipulate third-party websites. Popular apps like Instagram, Facebook Messenger and Facebook have all been caught injecting JavaScript via their in-app browsers into third party websites. TikTok was running commands that were essentially a keylogger. While we have no proof that this data was used or exfiltrated from the device, the mere presence of JavaScript code collecting this data combined with no plausible explanation is extremely concerning.
↫ Open Web Advocacy
Open Web Advocacy has submitted a detailed and expansive report to the European Commission detailing the various issues with these in-application browsers, and suggests a number of remedies to strengthen security, improve privacy, and preserve browser choice. I hope this gets picked up, because in-application browsers are just another way in which we’re losing control over our devices.
At this point you might well be writing about the death of the URI…
mailto:// is rare
tel:// is essentially non-existent
geo:// I have only seen in the RFC that specified it…
Why be surprised that http(s):// is going the same way.
I will keep saying it: Stallman was right. 40 years early, but right.
Stallman was right about a great many things, unfortunately.
Given to where things are heading to, soon, you will need to be a “authorized professional” to even have access to a compiler or development modes on any computing device, with violations of that being treated as criminal behavior.
Interesting take. I actually dislike having the browser tabs appear alongside applications for the same reason I dislike in-application browsers: I expect my open tabs to be contained within the browser, which has been my preferred experience ever since IE6 went out of fashion.
It is lovely in the Librem 5’s phosh: if you open new tabs, same application window. If you open a new browser tab, then you get a new application window (using Firefox at least).
It is a key part of my workflow.
Android used to have a notion of “Cards”, which may or may not be tied to an application.
That meant the developer would advertise what the app can do “will receive a {URL} and render it” as a capability and one single workflow would then jump between different apps as necessary. (Still somehow available in printing and sharing flows).
(Activities, Intents, and “magic” Intent Filter)
However this never actually caught on, and devs just wanted to stay within their card views that they have much tighter control about (can’t entirely blame them).
This change in UX approach led to major cascading UI changes as well. And the old android is no longer recognizable. The new one? As you mentioned a collection of walled gardens.
Luckily some website refuse to load when using a in-app browser, most notably that of my bank site. Unfortunately, it also doesn’t tell we what’s wrong, so it took a while before I understood why the QR code I scanned didn’t go the payment page…