rfc8252
I mostly work in backend data pipelines. That is where I have the most fun. But every product eventually drags you into UX, and this one started with what sounded like a trivial problem.
I posted a link. Someone clicked it from LinkedIn. Then they told me Google sign-in did not work.
At first, I thought the direction was obvious: tap the ellipsis, choose Open in Browser. That seemed self-explanatory. A couple of months later, I got basically the same complaint again.
Sigh.
I get it. If you are working 60 to 70 hours a week, worried about your livelihood, with the AI train roaring up behind you, you probably do not have the spare mental capacity to read three paragraphs of warning text.
Fine.
Why this is a problem at all
The warning is not just me being precious.
RFC 8252 says OAuth for native apps should use an external user-agent, meaning the real browser, not an embedded in-app browser. Google also documents a disallowed_useragent failure mode for embedded user-agents like WKWebView.
In plain English: the host app controls that browser surface and can observe or interfere with the auth flow.
So the ideal path is simple:
- user opens the page
- user gets pushed into a real browser
- sign-in happens there
That is the ideal.
Reality is uglier.
What I tried
I ended up testing the usual escape hatches.
Android
On Android, there is a documented intent: path that can hand off to Chrome, assuming the host app lets it:
intent://yourdomain.com/path#Intent;scheme=https;package=com.android.chrome;S.browser_fallback_url=https%3A%2F%2Fyourdomain.com%2Fpath;end
iOS Chrome
On iOS, Chrome exposes documented URL schemes:
googlechromes://yourdomain.com/path googlechrome://yourdomain.com/path
Other tactics
Before that, I also tried the usual lower-level nonsense:
- detect if the page is trapped in an iframe and try to break out to
window.top - detect obvious in-app browser markers in the user agent
- show a warning modal
- disable or gate sign-in in known-bad environments
- attempt browser handoff only after a real user tap, because automatic redirects or self-click tricks are usually blocked
Where it gets stupid
The most annoying part is that iPhone and iPad do not behave the same way.
On iPhone, I got something workable. The escape flow was at least real enough to use.
On iPad, especially inside LinkedIn, the same idea often just stayed trapped inside the in-app browser. Apple has been explicit that iPad uses more desktop-class browsing behavior, and those differences bleed into Safari-related browser surfaces and web views too.
So the same page, same host app, same intention, different device class, different result.
That is the kind of problem that makes you start talking to the ceiling.
The current compromise
So the current compromise is this:
- where the escape path is real enough to be worth trying, I show browser buttons directly
- where it is not, I stop pretending and just tell the user what to do
On iPad, that means instructions to hit the ellipsis and open the page in the real browser.
On other devices, it means giving browser handoff buttons a shot.
In my defense, I did try to make it work universally. But once the host app decides to keep the user inside its bundled browser, the webpage stops being in charge. That is the whole problem.
The real issue
The old mental model of the web was simple:
- a link opens in a browser
- the browser belongs to the user
- the site and the user deal with each other directly
The newer mobile reality is often this:
- a link opens inside another app
- the app keeps the user inside its own browser surface
- the site is allowed to exist only inside that rented hallway
The user thinks they opened the web.
What they often opened is a controlled environment pretending to be the web.
Conclusion
Some curb on these monopolistic platform behaviors is overdue.
In the meantime, we are left with a broken web:
- links that are not really links
- browsers that are not really browsers
- auth flows that become a jurisdiction dispute between your site, the host app, the OS, and the standards body that already warned everyone this was a bad idea
And all of this because someone clicked a link.
References
- RFC 8252, OAuth 2.0 for Native Apps
- Google OAuth documentation on
disallowed_useragent - Chrome URL scheme documentation for iOS
- Android intent URL documentation