When you tap a link in any social media app, you're not using your browser. You're using theirs.

That single sentence describes one of the most quietly invasive privacy practices in modern smartphone use—and most people have no idea it's happening. You tap a news article inside LinkedIn. You click a product link inside Instagram. You open a URL inside TikTok. In every one of those cases, the website loads inside a browser window that the app itself controls.

It is not the browser you chose. It is not the browser you configured for privacy. It is an embedded environment built by the application, designed to keep you inside its walls. Understanding how this architecture works changes the way you should think about every link you tap.

               Test Globally With LycheeIP

Your Browser vs. Their Browser

Let's start with the technical basics, because the distinction matters immensely.

When you open Safari, Firefox, or Chrome directly and visit a website, you are using a system browser—a fully independent application with a robust security model. These browsers isolate websites from one another via strict sandboxing rules, aggressively block third-party cookie tracking, and receive constant security patches.

An in-app browser is entirely different. It is a browser-like window that an application spins up inside its own process using frameworks called WKWebView (on iOS) or WebView (on Android). Think of it less like opening a new app and more like the host app creating a window to the internet—a window it built, controls, and can monitor from both sides.

WKWebView and WebView are legitimate developer tools. They exist for valid reasons: loading terms-of-service agreements, displaying help documentation, or rendering OAuth login flows. However, they also grant the host app a level of access to web content that no external browser would ever permit.

The critical technical point: when a website loads inside an in-app browser, the host app acts as a Man-in-the-Middle (MITM).

Security researcher Felix Krause demonstrated this vividly in 2022. He audited what Meta's apps were doing inside their iOS in-app browsers and found that Instagram and Facebook were injecting custom JavaScript code into every single website loaded through them. JavaScript injection allows the host app to run its own executable code on a page it didn't build—essentially reaching into a third-party website and adding an invisible surveillance layer on top.

Meta stated this was used for functionality like enabling payments and not for tracking. But the capability was there, the code was executing, and crucially, the user had no idea any of this was happening.

What They Can See That Safari Cannot

Here is where the technical explanation becomes genuinely alarming for everyday users and developers alike.

A normal website you visit in Safari or Chrome operates inside a tightly controlled environment. The browser limits what scripts can run, partitions cookies, and prevents any external application from intercepting what you type. Your bank login happens in a sandbox that no other app can look into.

In an in-app browser, those walls do not exist in the same way because the host app is already inside the sandbox. Depending on how it is implemented, an in-app browser can technically access:

• Keystroke logging: Every character you type into any form—search queries, passwords, credit card numbers—can be captured before it ever leaves your screen.
• Form data interception: When you enter a phone number or shipping address, that data passes through the in-app browser's layer and can be copied or transmitted.
• Scroll and tap behavior: The app can monitor how long you read a specific paragraph, which image you hovered over, or whether you lingered on a price tag. This behavioral telemetry is enormously valuable for building advertising profiles.
• Session and authentication data: If you open a link to a service you are already logged into, the in-app browser can potentially observe authenticated sessions in ways that are impossible when two separate apps are involved.
• Full DOM access: The app can read the complete HTML of every page you visit, including content the website considers private.

Not every app is necessarily doing all of these things right now. Companies have privacy policies and legal teams that create some accountability. But the architecture permits it, and that is the point. You are extending implicit trust to a social media company every time you tap a link.

LycheeIP (Developer-First Proxy Infrastructure)

For technical operators, growth teams, and developers, understanding how different browsers and network environments handle traffic is critical. LycheeIP is a developer-first proxy and data infrastructure provider designed to give engineering teams absolute control over their network routing, global testing, and automated data collection.

When your QA team needs to verify how your web application renders inside an embedded WKWebView across different geographic regions, testing from a single office IP is insufficient. By integrating a robust proxy network into your mobile testing pipelines, you can simulate global user sessions without triggering automated rate limits. For data teams tasked with scraping public social media links to analyze how competitors format content for in-app browsers, high-speed datacenter proxies ensure your extraction tasks run persistently and securely. Conversely, if you are conducting localized ad verification to see exactly what external users see when they click your links, utilizing dynamic IP routing allows your automated systems to mimic organic, residential traffic perfectly. Partnering with a reliable data infrastructure platform ensures that developers can build, test, and scrape with confidence, maintaining total visibility over how their assets perform in the wild.

               Test Globally With LycheeIP

How to Take Back Control

The good news is that the fix is simple, effective, and takes only a few minutes to implement across your most-used apps. The strategy is straightforward: force every app to open links in your real browser.

On LinkedIn

LinkedIn actually provides a direct setting for this. Go to your Profile Photo → Settings → Browsing and turn off Open links in LinkedIn app's browser. Every link you tap will now open securely in Safari or Chrome.

On Instagram and Facebook (Meta)

Meta does not make this easy; there is no clean toggle. The workaround is behavioral. When a link opens in the in-app browser, look for the three-dot menu or the Share button at the bottom of the screen and select Open in Browser. It is an extra tap every time, but it takes you out of Meta's environment.

On TikTok

TikTok has faced heavy scrutiny for its in-app browser behavior. When a link opens, tap the three-dot menu in the bottom right and select Open in Safari (iOS) or Open in Chrome (Android).

The System-Level Approach

• On iOS: Go to Settings, scroll to an individual app, and look for a Default Browser option or review the app-specific permissions.
• On Android: Navigate to Settings → Apps → Default Apps to designate Chrome or Firefox as your system browser. Well-behaved apps will route links there automatically.

The Broader Habit

Beyond settings, the most durable protection is a simple mental habit: treat any link opened inside a social media app as potentially observed. Do not enter passwords. Do not complete purchases. If the content matters, open it in your real browser.

Why This Matters Beyond Privacy

There is a secondary issue that rarely gets discussed: in-app browsers are objectively worse browsers.

They do not have your securely saved passwords. They lack your autofill information and your ad-blocking extensions. They frequently render pages poorly. You are not just accepting a privacy trade-off; you are getting a genuinely inferior product in exchange for the app's ability to keep you inside its ecosystem.

The in-app browser is, at its core, a retention mechanism dressed up as a convenience feature. The app keeps you inside its walls because every second you spend there can be monetized. Your attention, your data, and your browsing behavior are the product.

The next time you tap a link inside an app, ask yourself whose browser you are actually using. Then decide if that is the deal you want to make.

               Test Globally With LycheeIP

Frequently Asked Questions

Q: Is every in-app browser automatically spying on me?

A: Not necessarily. The architecture permits surveillance, but not every company actively exploits every capability. However, because the technical access exists and is largely invisible to users, cybersecurity guidelines—such as those discussed by the OWASP Foundation regarding client-side security—recommend treating in-app browsers as potentially observed environments.

Q: Does using a VPN protect me from in-app browser tracking?

A: No. A VPN encrypts the connection between your phone and the internet, protecting you from your ISP or network administrator. It does not prevent the app itself—which sits natively on your device—from reading what you type or observing your interactions.

Q: Is this only a problem on phones, or does it happen on desktop too?

A: This is primarily a mobile issue. Desktop applications like the LinkedIn or Facebook clients usually open links in your default system browser automatically because desktop OS architecture handles URL routing differently.

Q: Are there any social media apps that do NOT use in-app browsers?

A: X (formerly Twitter) and Reddit have, at various points, offered cleaner external browser redirect behaviors. However, app behavior changes with updates. An app that respects your default browser today may introduce an in-app browser tomorrow.

Q: Can websites detect that they are being loaded inside an in-app browser and refuse to load?

A: Yes, technically. Developers can inspect User-Agent headers and JavaScript environment properties (documented extensively on MDN Web Docs) to determine if they are rendering inside a WebView. Some security-sensitive services, like banking apps, do exactly this and force a redirect. However, most websites do not implement this check.

Q: What is JavaScript injection, and why is it significant?

A: JavaScript injection occurs when the host app inserts its own custom code into a webpage you are visiting. This code can monitor events, capture input, read DOM content, and report behavior back to the app. It is the technical mechanism that gives in-app browsers capabilities far beyond what a sandboxed browser would allow.