13 ms·

I generally don't see any appeal to in-app browsers in the first place. They often have extremely broken navigation controls (i.e. attempting to swipe back to a

I generally don't see any appeal to in-app browsers in the first place. They often have extremely broken navigation controls (i.e. attempting to swipe back to a previous page usually just returns back to the app), block the ability to navigate to a specific URL, content blockers don't work, don't allow opening "smart links" that would typically open in another app if opened from a normal browser, etc. From what I'm gathering from this article, it sounds like in-app browsing allows apps to give you all of the "benefits" of being tracked (for their benefit only), with none of the (actual) benefits of using a real browser.

samtheprogram 4y ago
Ironically the whole point of it originally was sandboxing, and it’s true at least on iOS. Thus, you won’t be logged into the same sites within an in-app browser, and clicking a link from within an app (whether it appears to be an link or not) can’t automatically connect you to cookies and any other tracking from your actual browser.
- tjoff 4y ago
  On android I have firefox-focus as my default browser (and disable any in-app browsing) for that same purpose.
  - flanbiscuit 4y ago
    Also available in Firefox for Android (not just FF Focus) Settings > Advanced > "Open links in apps" https://support.mozilla.org/en-US/kb/set-firefox-android-open-links-native-apps https://support.mozilla.org/en-US/kb/set-firefox-android-ope...
    - tjoff 4y ago
      The point with firefox focus is that the whole browser is in private mode. And even another browser, so no shared sessions or anything with your normal browser or precious interactions/sessions. Not sure if open-links-in-apps is comparable to that, never tried it (I rather prefer multitasking than doing it from within the app anyway).
darth_avocado 4y ago
I frankly am surprised why anyone would think otherwise? The “In-app” in the name should kind of give it away that it is, after all, in the app. Anything you do will be available for the app to track.
- lrvick 4y ago
  Consider the overwhelming majority of users are technically illiterate. Everything is just magic scrolling machines people learned to trust from watching people they trust use them.
  - darth_avocado 4y ago
    I would sympathize with all of the illiterate users. But the person who reported this and the people on HN discussing the article would be considered a little more technologically literate I would assume.
    - lrvick 4y ago
      It is our obligation as those that build technology to call out risks to the technically illiterate masses and be advocates for them.
- rchaud 4y ago
  Considering that a simple iOS privacy disclosure dialog box cost FB $10bn in revenue loss, I'd say there are a lot of things users would be surprised to know when it comes to how apps work and what they collect.
mrtksn 4y ago
On iOS this is traditionally done with UIWebView or WKWebView(like the former but better performance, runs as separate process) and you are right about the problems it creates. However, the developers do have options to incorporate SFSafariViewController since iOS9.0 and that gives the user full Safari experience with Autofill and everything and without giving access to its contents to the app developer. It actually makes a lot of sense from users perspective when the context is that the app temporary needs to take you to a webpage for something with the intention of you going back to the app. With SFSafariViewController this is done securely and with good user experience but unfortunately most apps business model revolves around tracking everything you do and as a result, most developers would use UIWebView/WKWebView instead of SFSafariViewController just to be able to track you. The UIWebView/WKWebView has legitimate uses like letting you sign in from a web interface and transfer the session into the app but I kind of feel like we would be better off to depreciate it in favour of using alternative methods to do the web/app connection and improve privacy significantly. Personally, I would never do anything sensitive from within a browser that is in an app. It looks like very obvious attack vector to me.
zippergz 4y ago
I'm sure this has gotten better as people have become more used to smartphones, but I worked on a popular app for a big company a number of years ago, and we would send people out to Safari to open links. The number of customer service calls we got from people who couldn't figure out how to get back to the app after that was ASTOUNDING. We eventually gave in and did an in-app browser. Not only did it get rid of that category of call, but it also noticeably helped our key metrics because fewer people were leaving the app to never come back again. I realize that doesn't address the appeal FOR USERS, but it is why we did it as developers.
- thrashh 4y ago
  I’m a developer and I remember turning off in-app browsers whenever I could and I absolutely hated it My browser would get littered with old tabs and coming back to the app for a small click became a hassle On the off-chance I do want to save a link, I know I can just open it in my browser anyway So I much prefer in-app browsers as a user and a developer
  - modeless 4y ago
    I'm the opposite, I hate in app browsers as a user. It's like having a bunch of extra poorly made web browsers that can only have one tab, and block me from using one of my apps. When I'm trying to find a tab I had open now I have to search both my browser tabs and every app in my app switcher. And if I want to keep using an app but it's showing an in-app browser I have to either throw away my tab, or navigate a menu to migrate it to my real browser to save for later, then switch back to the app and close the in app browser, and only then can I continue to use the app. It's a constant pain.
  - shawnz 4y ago
    I think Android's "custom tabs" functionality is a great compromise. Apps can open a separate instance of the user's default browser which becomes part of the app's activity stack and doesn't share tabs with the main browser instance. However the UI and navigation are controlled by the browser, not the app. Cookies and local storage are also shared with the main browser instance, allowing seamless SSO without the app being able to intercept the secrets. AFAIK iOS supports something similar, but only for authentication use cases.
tolmasky 4y ago
It's even worse than that: 1. Nothing you visit gets saved in your history. So many times I'm looking through my history thinking "I could have sworn I read an article about this..." only to eventually discover (if I'm lucky) that it was in Twitter's stupid in-app browser. But oh well, never going to find that article again! The irony of the APP knowing everything you visit but you never getting to remember what you visited. 2. All your logins are gone! I actually pay a bunch of stupid newspapers just to click on links in Twitter and STILL be told I can't read the article because of course I'm not logged-in in the in-app browser. UGH. You could imagine a world where iOS tried to balance the desire of an app to not bounce you out with a more "integrated experience" by providing an "in-app" browser that was completely controlled by the OS, modifying your history, keeping you logged in, running out of process, and being able to be "adopted" as a tab in Safari, but instead they just made "SFSafariViewController" which does none of these things and instead just makes it really really easy for all apps to incorporate these infuriating in-app browsers.
- mrtksn 4y ago
  > instead they just made "SFSafariViewController" which does none of these things Actually, SFSafariViewController acts as a full Safari without giving any ability to the developer to inject scripts or receive data to track you(except for ad taps through Private Click Measurement). It's actually a nice solution, it shares cookies(non-session ones) with Safari.
  - tolmasky 4y ago
    Right... by "none of these things" I meant... the stuff I listed, which for the record is not incompatible with isolating the browser from the initiating app. It would be totally viable to give SFSafariViewControllers "write only" access to your history (implemented as just an API call that SFSafariViewControllers makes to notify the OS of a page navigation, which it can then store the URL of in your history, so that when you go to history in Safari later, it would show up there). Similarly, there could be a very nice "adopt as tab" button that would "rip" the view controller out of the enclosing app and just plop it into Safari proper, complete with it's back-forward list/history, and make it really easy to transition from the app to Safari without the much less ideal "open in Safari" button that loses navigation/page-state/etc. In other words, the way SFSafariViewController could work is that you are in Safari (forcing the full screen experience), just with a "Done" button that takes you "back" to the app (or an adopt button that "solidifies" the app switch. Think something more akin to the "app banner" that Safari shows when you go to an app's page, just with a nice transition of the webpage coming in from the app, kind of like the old Mail animation from iOS 1). This actually accommodates both goals: you get the real "full Safari" (again, you have effectively opened the link in Safari), but a nice little "Done" button to let you get back to what you were doing in the initiating app, which is the only "good faith" thing the app should care about (obviously we don't care about accommodating tracking/etc.).
nerdponx 4y ago
There is no appeal for users and there never has been.
systemvoltage 4y ago
Instagram isn’t doing it for the benefit of the user.
stingrae 4y ago
My assumption is that it is a Product managers play to get people to stay in the app for longer. If you give people a link out of the app, then they are less likely to come back after. You get a bump in engagement and time spent in the app at the cost of UX.
inlined 4y ago
The appeal of in-app browsers is that apps like Facebook can boost their “time in app” metrics while you read linked articles.
the_gipsy 4y ago
They lock users into the app. Every app and website tries hard to not let the user follow a link. Engagement.
sayrer 4y ago
Well, I'm sure there are "growth hacker" types out there abusing the ability to observe browsing. But I think the real reason they don't bounce you to Safari, Chrome, etc is because users don't stay in the app if they do that. I think all of the various bad things people talk about here must happen sometimes, but it's mostly just retention I'd guess.
zionic 4y ago
> i.e. attempting to swipe back to a previous page usually just returns back to the app Is there any way to turn that damn functionality off? I can’t tell you how many times I’ve been navigating some newfangled web UI and had a swipe go “back”. That and disabling pinch to zoom backing out to the tabs UI. I wanna zoom out dammit. Is hitting a back or tab button really so hard that you have to break basic pan/zoom mechanics?! I know I’m putting off “old man yells at cloud” vibes here, but come on
rconti 4y ago
The very first thing I do, every time, is click "open in browser", just because, if nothing else, the framing of the site always feels "off" to me when using one of those in-app browsers.

samtheprogram 4y ago

Ironically the whole point of it originally was sandboxing, and it’s true at least on iOS. Thus, you won’t be logged into the same sites within an in-app browser, and clicking a link from within an app (whether it appears to be an link or not) can’t automatically connect you to cookies and any other tracking from your actual browser.

tjoff 4y ago
On android I have firefox-focus as my default browser (and disable any in-app browsing) for that same purpose.
- flanbiscuit 4y ago
  Also available in Firefox for Android (not just FF Focus) Settings > Advanced > "Open links in apps" https://support.mozilla.org/en-US/kb/set-firefox-android-open-links-native-apps https://support.mozilla.org/en-US/kb/set-firefox-android-ope...
  - tjoff 4y ago
    The point with firefox focus is that the whole browser is in private mode. And even another browser, so no shared sessions or anything with your normal browser or precious interactions/sessions. Not sure if open-links-in-apps is comparable to that, never tried it (I rather prefer multitasking than doing it from within the app anyway).

darth_avocado 4y ago

I frankly am surprised why anyone would think otherwise? The “In-app” in the name should kind of give it away that it is, after all, in the app. Anything you do will be available for the app to track.

lrvick 4y ago
Consider the overwhelming majority of users are technically illiterate. Everything is just magic scrolling machines people learned to trust from watching people they trust use them.
- darth_avocado 4y ago
  I would sympathize with all of the illiterate users. But the person who reported this and the people on HN discussing the article would be considered a little more technologically literate I would assume.
  - lrvick 4y ago
    It is our obligation as those that build technology to call out risks to the technically illiterate masses and be advocates for them.
rchaud 4y ago
Considering that a simple iOS privacy disclosure dialog box cost FB $10bn in revenue loss, I'd say there are a lot of things users would be surprised to know when it comes to how apps work and what they collect.

mrtksn 4y ago

On iOS this is traditionally done with UIWebView or WKWebView(like the former but better performance, runs as separate process) and you are right about the problems it creates. However, the developers do have options to incorporate SFSafariViewController since iOS9.0 and that gives the user full Safari experience with Autofill and everything and without giving access to its contents to the app developer. It actually makes a lot of sense from users perspective when the context is that the app temporary needs to take you to a webpage for something with the intention of you going back to the app. With SFSafariViewController this is done securely and with good user experience but unfortunately most apps business model revolves around tracking everything you do and as a result, most developers would use UIWebView/WKWebView instead of SFSafariViewController just to be able to track you. The UIWebView/WKWebView has legitimate uses like letting you sign in from a web interface and transfer the session into the app but I kind of feel like we would be better off to depreciate it in favour of using alternative methods to do the web/app connection and improve privacy significantly. Personally, I would never do anything sensitive from within a browser that is in an app. It looks like very obvious attack vector to me.

zippergz 4y ago

I'm sure this has gotten better as people have become more used to smartphones, but I worked on a popular app for a big company a number of years ago, and we would send people out to Safari to open links. The number of customer service calls we got from people who couldn't figure out how to get back to the app after that was ASTOUNDING. We eventually gave in and did an in-app browser. Not only did it get rid of that category of call, but it also noticeably helped our key metrics because fewer people were leaving the app to never come back again. I realize that doesn't address the appeal FOR USERS, but it is why we did it as developers.

thrashh 4y ago
I’m a developer and I remember turning off in-app browsers whenever I could and I absolutely hated it My browser would get littered with old tabs and coming back to the app for a small click became a hassle On the off-chance I do want to save a link, I know I can just open it in my browser anyway So I much prefer in-app browsers as a user and a developer
- modeless 4y ago
  I'm the opposite, I hate in app browsers as a user. It's like having a bunch of extra poorly made web browsers that can only have one tab, and block me from using one of my apps. When I'm trying to find a tab I had open now I have to search both my browser tabs and every app in my app switcher. And if I want to keep using an app but it's showing an in-app browser I have to either throw away my tab, or navigate a menu to migrate it to my real browser to save for later, then switch back to the app and close the in app browser, and only then can I continue to use the app. It's a constant pain.
- shawnz 4y ago
  I think Android's "custom tabs" functionality is a great compromise. Apps can open a separate instance of the user's default browser which becomes part of the app's activity stack and doesn't share tabs with the main browser instance. However the UI and navigation are controlled by the browser, not the app. Cookies and local storage are also shared with the main browser instance, allowing seamless SSO without the app being able to intercept the secrets. AFAIK iOS supports something similar, but only for authentication use cases.

tolmasky 4y ago

It's even worse than that: 1. Nothing you visit gets saved in your history. So many times I'm looking through my history thinking "I could have sworn I read an article about this..." only to eventually discover (if I'm lucky) that it was in Twitter's stupid in-app browser. But oh well, never going to find that article again! The irony of the APP knowing everything you visit but you never getting to remember what you visited. 2. All your logins are gone! I actually pay a bunch of stupid newspapers just to click on links in Twitter and STILL be told I can't read the article because of course I'm not logged-in in the in-app browser. UGH. You could imagine a world where iOS tried to balance the desire of an app to not bounce you out with a more "integrated experience" by providing an "in-app" browser that was completely controlled by the OS, modifying your history, keeping you logged in, running out of process, and being able to be "adopted" as a tab in Safari, but instead they just made "SFSafariViewController" which does none of these things and instead just makes it really really easy for all apps to incorporate these infuriating in-app browsers.

mrtksn 4y ago
> instead they just made "SFSafariViewController" which does none of these things Actually, SFSafariViewController acts as a full Safari without giving any ability to the developer to inject scripts or receive data to track you(except for ad taps through Private Click Measurement). It's actually a nice solution, it shares cookies(non-session ones) with Safari.
- tolmasky 4y ago
  Right... by "none of these things" I meant... the stuff I listed, which for the record is not incompatible with isolating the browser from the initiating app. It would be totally viable to give SFSafariViewControllers "write only" access to your history (implemented as just an API call that SFSafariViewControllers makes to notify the OS of a page navigation, which it can then store the URL of in your history, so that when you go to history in Safari later, it would show up there). Similarly, there could be a very nice "adopt as tab" button that would "rip" the view controller out of the enclosing app and just plop it into Safari proper, complete with it's back-forward list/history, and make it really easy to transition from the app to Safari without the much less ideal "open in Safari" button that loses navigation/page-state/etc. In other words, the way SFSafariViewController could work is that you are in Safari (forcing the full screen experience), just with a "Done" button that takes you "back" to the app (or an adopt button that "solidifies" the app switch. Think something more akin to the "app banner" that Safari shows when you go to an app's page, just with a nice transition of the webpage coming in from the app, kind of like the old Mail animation from iOS 1). This actually accommodates both goals: you get the real "full Safari" (again, you have effectively opened the link in Safari), but a nice little "Done" button to let you get back to what you were doing in the initiating app, which is the only "good faith" thing the app should care about (obviously we don't care about accommodating tracking/etc.).

nerdponx 4y ago

There is no appeal for users and there never has been.

systemvoltage 4y ago

Instagram isn’t doing it for the benefit of the user.

stingrae 4y ago

My assumption is that it is a Product managers play to get people to stay in the app for longer. If you give people a link out of the app, then they are less likely to come back after. You get a bump in engagement and time spent in the app at the cost of UX.

inlined 4y ago

The appeal of in-app browsers is that apps like Facebook can boost their “time in app” metrics while you read linked articles.

the_gipsy 4y ago

They lock users into the app. Every app and website tries hard to not let the user follow a link. Engagement.

sayrer 4y ago

Well, I'm sure there are "growth hacker" types out there abusing the ability to observe browsing. But I think the real reason they don't bounce you to Safari, Chrome, etc is because users don't stay in the app if they do that. I think all of the various bad things people talk about here must happen sometimes, but it's mostly just retention I'd guess.

zionic 4y ago

> i.e. attempting to swipe back to a previous page usually just returns back to the app Is there any way to turn that damn functionality off? I can’t tell you how many times I’ve been navigating some newfangled web UI and had a swipe go “back”. That and disabling pinch to zoom backing out to the tabs UI. I wanna zoom out dammit. Is hitting a back or tab button really so hard that you have to break basic pan/zoom mechanics?! I know I’m putting off “old man yells at cloud” vibes here, but come on

rconti 4y ago

The very first thing I do, every time, is click "open in browser", just because, if nothing else, the framing of the site always feels "off" to me when using one of those in-app browsers.