, 23 tweets, 4 min read Read on Twitter
To clarify for non-tech folk: TL;DR, there's a silent browser war afoot -- a tug-of-war between apps and real browsers.

Some apps use technology designed to show in-app content to render (unsafe) out-of-app content. This endangers privacy, but also hurts the web.
I say "silent" because the UI presented by real browsers via Chrome Custom Tabs (CCT) and legacy "in-app browsers" based on WebView is often hard to spot:

developer.chrome.com/multidevice/an…
To see which approach an app is taking, click on a link that doesn't take you "all the way out" to a browser and look for the 3-dot menu (or equivalent). If it has a "Powered by <Browser>" item at the bottom of the menu, it's CCT:

developer.chrome.com/multidevice/im…
If you *don't* see that, you're dealing with a WebView -- which is the app doing a *very bad thing*.

What's the difference? Buckle up, this gets slightly technical. WebView is a system component of Android. These days, it auto-updates, but didn't always do so.
WebViews were designed for loading content *from the app* into the app. That is, stuff it trusts. The threat model both from security and privacy is pretty straightforward.

Things get funky when you load stuff from other parties.
Browsers, on the other hand, are designed to update outside the OS update cycle and fundamentally mistrust content -- they're the *user's* agent, rather than an app component.
This difference runs deep, but the most important thing to understand is that users choose browsers. That's an intentional preference that should mean something.
When apps use CCT to load third-party content, they are _respecting user choice_. But they're also practicing security hygiene and acting as good web citizens. Why?

First, WebView puts the problem of loading content onto the app. This means that apps *incidentally* see plaintext
CCT invocation, on the other hand, delegates this problem to the user's default browser. And browsers spend a _lot_ of time and effort getting transport security and UI indicators about safety right.

Now, OS vendors realized that this was happening and have responded (a bit).
Modern WebView on Android is powered by an auto-updating Chrome. But that still leaves ~8% of devices without up-to-date WebView runtimes:

developer.android.com/about/dashboar…
...for context, that's almost half the number of people with iPhones. The scale of Android is mind-boggling.

But even with auto-updating WebView handling (some of) the security aspects, the privacy issue remains. WebViews aren't browsers.
Installing a different browser as your default on the system doesn't change the app's WebView implementation. Sure, they can bring their own (super common in CN), but user choice and privacy is undermined. The app *still gets to see everything you do in the WebView*.
...every keystroke you type, every password you enter, every site you go to in that session. You're now trusting the parent app with *everything*.

You installed Brave or Samsung Internet or Opera or FF as your default browser? Tough. In-app, WebView-based browsers DGAF.
...whereas CCT puts your browsing back in your hands. With CCT, your choices matter, and bowsers can compete on security/privacy/tracking/etc.
There's a further issue, though. WebViews aren't meant to be full implementations of the web platform. They're sort of halflings: some core stuff is built-in, but anything that reaches outside of the renderer -- APIs that do something other than CSS/HTML/JS -- is often busted.
This makes WebView based in-app "browsers" totally broken from the perspective of the web platform. They are boat-anchors for progress on the web, even when they're built form exactly the same source code.
But as much as *I* care about that, it's something of a minor point in the grand scheme.

The big issue here is privacy. And WebViews are even worse than just letting the app itself sniff and rewrite all the pages you see...

...remember those out-of-date WebViews?
Attacks against WebViews aren't just attacks against the pages, they're attacks against *the host app*. Everything you trusted it with.
Now, again, OS vendors are doing a ton to try to fix webviews...but the model is just busted. The attack surface area isn't just the web platform, it's every API the host app bolts on or intercepts. Disaster in the making.
WebViews for non-app content are a choice that apps make. Other, better, more respectful and secure choices are available to them. Apps that insist on not taking you out to your browser when you tap on links, but also do not take advantage of CCT/SafariViewController are *bad*.
Cannot stress this enough: the only reason this happens is because apps are jealous of your time. They build these upside-down "browsers" because they don't want you to go to your real default browser. They want to keep you in-app.

They *worked* to break this.
The default behavior for navigation intents is to launch your default browser. Many apps felt this wasn't in their interest, so they put your privacy and security at risk.

Demanding they adopt CCT is the *least* we can ask.
So when companies start taking about taking privacy seriously but still default hundreds of millions of users to this dog's breakfast of a broken, privacy violating web experience, don't believe a word of it.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Alex Russell
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!