Habits the phone taught you · habit 11 of 40

It opens in the app, not the browser

You tapped a link expecting your browser and got a page inside a chat app, with a header at the top and no address bar. Nothing went wrong. The platform did what it was configured to do, by the app rather than by you.

The habit

You tap the link because tapping the link is the entire interface of a phone.

Why it is automatic

Nobody chose this arrangement. Apps register the kinds of link they can handle when they are installed and the system honours the registration, so the app that handles a tap is decided by what you installed rather than by what you intended. There was no dialogue and no preference screen.

It works so smoothly that most people have never noticed it happening. The page appears and it looks close enough to a browser. A small header with the app name and a cross is the only visible difference.

The habit is reinforced by how bad the alternative feels. Copying an address, switching apps, pasting and pressing go is four actions instead of one, on a device where every extra action is felt.

What it actually does here

The embedded browser is a separate browser. It has its own cookie store, its own cache and its own settings, and nothing you configured in your real browser applies inside it. Whatever you turned off, whatever you set to ask first: none of it is present in a window an app draws inside itself.

The network path is the app's path rather than yours. The request leaves through code the app controls, and whatever that code does for its own ordinary reasons happens to your request too. The page may also have been fetched before you tapped, to produce the preview card in the conversation.

The tap is an event in somebody else's software. The app that handled it knows a link was opened, at a time, from a conversation, by an account, and the message stays in the thread on both sides. That is easy to miss, because the visible consequence is a page loading.

None of this involves anybody misbehaving. It is the ordinary operation of link handling, in-app browsing and preview generation. It only means the browser you carefully chose was not involved in the page you just read. If the link arrived from a person, the surrounding habits are on the people section.

The browser you configured was not the browser that opened

This is the practical core of the page. Somebody sets a browser up properly, gets the settings the way they want, then reads a page in a completely different browser without realising, because the window looked similar enough. Every setting is a property of one browser rather than of the phone.

The tells are small. No address bar, or one that cannot be tapped. A header strip in the app's colour. A cross rather than a back arrow. Once you know them you see them immediately, and before that they are invisible.

A tap is an event in somebody else's app

People think about links as things they read, so the record of having tapped one does not feel like content. It is content. A tap is timestamped, attached to an account, and kept by an organisation with no particular reason to discard it. That is why the answer here is about moving the address rather than about which app to trust.

Who decided

The app registered a link type at install time and the system honoured it

Which browser

One embedded in the app, with storage and settings of its own

What is kept

The message in the thread, and the fact of the tap, on the app's side

What to do instead

The fix here is mechanical and it is the same on every phone: stop the tap from being the thing that opens the page.

1. Do not tap a link that arrived inside another app. Open the browser you meant to use first, then bring the address to it.
2. Where you have to move a string, long press and copy rather than tap, and read the clipboard that remembers first, because that route has a cost of its own.
3. Look in the settings of the messaging and social apps you use for an option to open links in the system browser, and turn it on where it exists.
4. If a page opened inside an app, close it and open it again properly rather than carrying on because it already loaded.
5. Keep the reading and the messaging on different machines where you can, so a tap in one cannot open a page in the other.

How to notice you did it anyway

The clearest signal for this habit is an absence rather than a trace, which makes it worth checking deliberately.

• Look in your browser history for the page you read. If it is not there, you did not read it in your browser.
• Look at the top of the window while a page is open. No address bar, or an app coloured header, means an embedded browser.
• Open the history inside the app itself, where it keeps one, and see what it has recorded.
• Check which app is currently set as the handler for links in your system settings.
• Look at your open tabs afterwards. A page read in an embedded browser leaves none.

What readers ask about this habit